I was reading about JSF that it's a UI framework and provides some UI components. But how is it better or different from number of components that are available from jQueryUI, AngularJS, React, Vue.js, Svelte, ExtJS, or even plain HTML, CSS and JavaScript.
Why should someone learn JSF?
JSF to plain JSP/Servlet/HTML/CSS/JS is like as jQuery to plain JS: do more with less code. To take PrimeFaces (jQuery + jQuery UI based) as an example, browse through its showcase to see complete code examples. BootsFaces (jQuery + Bootstrap UI based) has also a showcase with complete code examples. If you study those examples closely, then you'll see that you basically need a simple Javabean class as model and a XHTML file as view.
Note that you should not see JSF as replacement of alone HTML/CSS/JS, you should also take the server side part into account (specifically: JSP/Servlet). JSF removes the need of all the boilerplate of gathering HTTP request parameters, converting/validating them, updating the model values, executing the right Java method to do the business stuff and generating the HTML/CSS/JS boilerplate code. With JSF you basically end up with a XHTML page as view definition and a Javabean class as model definition. This greatly speeds up development.
As with every component based web MVC framework, you have in JSF less fine-grained control over the rendered HTML/CSS/JS. Adding custom JS code isn't that easy as you have to take the JSF view state in the server side into account as well (e.g. enabling a disabled button in JS side won't enable the button in JSF side, which is in turn a huge security advantage). If that is however a major showstopper, then rather look for an action based web MVC framework like Spring MVC. You'll only take into account that you have to write all that HTML/CSS/JS code (and prevention against XSS, CSRF and DOM-manipulation!) yourself. Also if you fall back from Facelets to JSP, you'll miss advanced templating capabilities as well.
On the other hand, if you have a big JSP/Servlet/HTML/CSS/JS/jQuery based website and you'd like to refactor the repeated JSP/Servlet/HTML/CSS/JS/jQuery boilerplate code into reusable components, then one of the solutions would be JSF. Custom templates, tagfiles and components can aid in this. In that perspective, JSF stands above JSP/Servlet/HTML/CSS/JS/jQuery (and that's also why it's pretty important to understand those basics before diving into JSF).
You can find a real world kickoff JSF based project here: Java EE Kickoff App. You'll see that it contains next to JSF as good HTML5, CSS3 and jQuery.
See also:
Difference between Request MVC and Component MVC
Difference between JSP, Servlet and JSF
What are the main disadvantages of JSF 2.0?
Is it possible to use JSF+Facelets with HTML 4/5?
When to use <ui:include>, tag files, composite components and/or custom components?
JSF was created to make it so that java shops didn't have to learn stuff like jQuery and build complex JS but instead focus on a purely Java stack. In a world where time is money and lots of places already focusing on Java development, one less language/piece in the stack makes training and maintaining faster and thus cheaper.
I'll add that JavaScript is easy to become a maintenance nightmare on large teams, especially if some of the developers on the project are not highly web savvy.
With Javascript and frameworks such as jQuery you have full flexibility and full control . With ext's etc you lose much control and must adapt to the framework. With JSF you totally lose control and must totally adapt to the framework. You're invoked in lifecycles etc. and finally you have no control when the call to the server can be made and where not. If you are to do something considered 'special', you're in very hard position. And in JSF world even such basic things as multicolumn table sort or fields where you can type only limited set of characters (such as number field) are considered 'special'.
However, the more flexibility you have, the more errors or bad practices you can made. High flexibility works only with highly intelligent programmers, others will turn the project into unmanagable nightmare.
But, with JSF and its limited flexibility, there's always only a few (or even only one) correct way to do something. You are very limited, you can't make shortcuts, you must write more XML etc. - but when adapting to standard, there's better control on the code the unexperienced or low-skilled programmers will produce. As a result, big corporations love JSF because it is 'safer' for them.
When I moved from GWT to JSF, I was shocked, how many things, that was natural to me, was considered highly untypical and how much simple things were so hard to achieve. What's more, even making the smallest changes, such as adding ':' sign after label, which in GWT/jQuery powered app would be changing one function generating label, required changing dozens of files with localized properties, which wasn't even considered by anyone except me strange...
The benefits of using JSF are not only in generating xhtml + css + js. Sometimes JSF imposes a restriction on the markup you can generate, like any component based framework. But JSF is not just for that, its lifecyle helps greately. After validating the input it can update the model and sync your server side beans without any effort. you just say "whatever the user types here, check if it's a number, if yes then store it in the property YY in object XX" and JSF will do all that.
So yes, you can still use JQuery, JS, etc. But JSF provides many benefits when it comes to writing server side code and saves you from a lot of boiler plate.
I strongly disagree that jsf adds anything. It only adds overhead. Doing ui stuff on the server is the most ridiculous thing ive ever heard. And javascript on large teams works great - its called reusing code.
Just wrap the jquery in some jsp tags, thats all you need and youre done, and dont endure the.shackles and scalability issues with.jsf and richfaces.
Having worked with JSF, Spring MVC, Struts, Grails, JQuery, and ExtJS my opinion is that Grails + ExtJS is one powerful combination.
I would pick Grails over JSF any day. I like the completeness of ExtJS as the client side framework and library, but it comes with a steeper learning curve than JQuery.
Here are the biggest differences between jQuery & JSF:
no MVC architecture
no state control (store date in session or conversation, auto-clean up, etc.)
no (default) validation library
no templating library
no advanced navigation/routing
client side
jQuery was never intended to be used as a full stack webframework. It was more intended for replacing low-level JS code so that writing JS becomes easier and more powerfull in less lines of code.
And it should thus mostly be used to add behaviour on HTML elements.
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.
Related
I have to decide on the view layer technology to use with Spring MVC 3 and I came across Thymeleaf.
Has anybody worked with Thymeleaf or has any experience with it. What will I gain and miss if I happen to choose it to work with Spring 3.
I wanted my front end designers to feel comfortable was why I was thinking if I could use thymeleaf with Spring 3 and still have all the functionalities we get with JSPs + Spring MVC 3.
Thymeleaf and Spring are a very nice match. The spring integration of Thymeleaf is done as it's supposed to be and it was nicely documented how to get started.
I use this combination since one year in several projects and I'm still happy with the choice I've made at the time.
Thymeleaf propagates the so called "Natural templating", which means that the templates can be viewed without the template engine, they are html files with additional tag attributes which browsers just ignore.
This means that a webdesigner can design the page, hand it over to the developer and get back again if changes to the layout have to be made.
While I liked this idea a lot in the beginning, I soon realized that, as developers, we tend to create components to be reused. This results often in templates having either not alot to display or also an extreme amount of elements.
Imagine some switch statement in a table cell component which renders either checkbox, textfield, select box, and so on. The table template including this cell fragment does not resolve it without an engine. Or imagine the header fragment with all the style and js declarations. Css will not be available in plain file mode.
But you can add additional html tags and remove them during processing. So natural templating is still possible. Just a lot to write :)
There are support extensions around solving this issues (using JS to pull in the fragments for example) but I havent used them as my applications are normally deployed within 30sec and I'm even able to change the templates on the fly without a redeploy.
After you also have a quite nice eco system around thymeleaf. The ability to extend Thymeleaf is done in a way I really enjoy! (Having written two smaller extensions myself).
I prefer the layout dialect instead of the include approach. That's a matter of taste i would say.
Choosing Thymeleaf over Plain JSP is clearly favorable from my point of view. Take a look at the webpage and decide for yourself ;)
I'm working with Spring 3 and Thymeleaf for a year and think it's a good choice. I came from Grails and Play and look for a good alternative and created FuWeSta. You can look at the rudimetar sample-app.
My project's domain is of eTendering. And we are planing to use Spring and Hibernate in the architecture and in presentation Spring MVC but we want look and feel like silverlight of .Net or Flex of adobe in short we are planning for Ajax framework in presentaion. So SpringMVC will be worthfull? I have seen wicket and openxava but I am still confused so please suggest correct option in terms of my domain's complexity.
Depends on your needs:
Spring MVC - this option will leave you with writing AJAX on your own (via JQuery for instance) along with HTML and so forth. It might be tedious, but you're controlling everything. It's also up to you what will be the quality of your resulting HTML and how good it will be indexed by SEO.
JSF - this option provides you with a number of components and allows you to create AJAX based forms and handles it out-of-box. But when it comes to writing custom components, it won't that easy as just writing JS/JQuery on your own. Also it generates not that pretty HTML which is not of that good quality and you might be less indexed by SEOs.
GWT - this choice would mean that you don't write JS, instead you write logic in Java and then it transforms to JS. From one hand it will provide you with good-looking AJAX-based app where you don't need to write JS, from the other hand it's a) pretty complicated to write really good-looking apps UI b) it will add another step in your development cycle (it takes pretty much time when you generate that JS) c) it almost won't allow your pages to be indexed. Also, if it comes to such derivatives as SmartGWT, they provide a large set of cool-looking components, but they always require money for support.
Vaadin - this is AJAX based framework that partially generates Java to JS, but it also sends requests go server for logic execution (of course in GWT this happens as well, but not that often, GWT tries to execute logic on client). It takes less time to compile sources to JS and it's also almost impossible to make pages being indexed.
ZK - another AJAX based framework. unlike other frameworks that allow you to work with only one pattern, it can work in MVC, MVP, MVVM modes. It doesn't compile Java sources to JS thus all the requests go to the server (I've heard about internal company's benchmarks that showed it was actually faster than GWT, but I think it depends on your processing logic). SEO won't make it with ZK at all, but it's possible to include ZK components into JSP pages (though this functionality is not free) which makes it possible to kill both birds. It will be not trivial to write your own components with ZK, but it has a wide range of ready-to-use components.
So you should consider several things: SEO, money you can give for the framework, how much AJAX you need and do you want to write it on your own, etc.
Also pay attention to those patterns I mentioned: MVP for instance is suitable for complicated interfaces and is supported by GWT, Vaadin, ZK. MVVM is very cool because of its binding and is supported by JSF and ZK.
I have to choose right js framework for web project. The structure of project consist from two separate modules:
1) Backend which sends data in xml/Json formats
2) html5 + JavaScript which receives data from backend and display it in browser.
Our team would be responsible for UI and JavaScript. I need to choose javascript framework.. (jQuery, ExtJs, Mootools, Prototype, DoJo, YUI, etc)
The ui is not complex but it contains small photo gallery, paging, popups, a lot of ajax, cross browsing..
How good is your team with CSS and Browser Compatibility?
If the answer is "not very" then I would suggest a rich framework such as ExtJs or DoJo that produces the html/css content for you.
If you are reasonably competent, then a behaviour only framework such as jQuery would give you more flexibility. There is of course also jQuery-UI which builds on jQuery base but falls into the first category.
Also be mindful of the future usefulnes of the skillsets required - good HTML/CSS/jQuery skills are widely used. By comparison few projects will use extJS. You may have a difficult job providing this as a rationale to management, but hopefully you get my point.
Perhaps the following reference may also help you decide?
http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks
I just started a new GWT project for a client and I'm interested in hearing people's experience with various GWT MVC architectures. On a recent project, I used both GXT MVC, as well as a custom messaging solution (based on Appcelerator's MQ). GXT MVC worked OK, but it seemed like overkill for GWT and was hard to make work with browser history. I've heard of PureMVC and GWTiger, but never used them. Our custom MQ solution worked pretty well, but made it difficult to test components with JUnit.
In addition, I've heard that Google Wave (a GWT application) is written using a Model-View-Presenter pattern. A sample MVP application was recently published, but looking at the code, it doesn't seem that intuitive.
If you were building a new GWT application, which architecture would you use? What are the pros and cons of your choice?
Thanks,
Matt
It's worth noting that google has finally written out a tutorial for designing using the mvp architecture. It clarifies a lot of the elements from the google i/o talk listed above. Take a looK: https://developers.google.com/web-toolkit/articles/mvp-architecture
I am glad this question has been asked, because GWT desperatley needs a rails-like way of structuring an application. A simple approach based on best practices that will work for 90 % of all use-cases and enables super easy testability.
In the past years I have been using my own implementation of MVP with a very passive view that enslaves itself to whatever the Presenter tells him to do.
My solution consisted of the following:
an interface per widget defining the methods to control the visual appearance
an implementing class that can be a Composite or use an external widget library
a central Presenter for a screen that hosts N views that are made up of M widgets
a central model per screen that holds the data associated with the current visual appearance
generic listener classes like "SourcesAddEvents[CustomerDTO]" (the editor does not like the real symbols for java generics here, so I used thoe brackets), because otherwise you will have lots of the same interfaces who just differ by the type
The Views get a reference to the presenter as their constructor parameter, so they can initialize their events with the presenter. The presenter will handles those events and notify other widgets/views and or call gwt-rpc that on success puts its result into the model. The model has a typical "Property[List[String]] names = ...." property change listener mechanism that is registered with the presenter so that the update of a model by an gwt-rpc request goes to all views/widgets that are interested.
With this appraoch I have gotten very easy testability with EasyMock for my AsynInterfaces. I also got the ability to easily exchange the implementation of a view/widget, because all I had to rewrite was the code that notified the presenter of some event - regardless of the underlying widget (Button, Links, etc).
Problems with my approach:
My current implementation makes it hard to synchronize data-values between the central models of different screens. Say you have a screen that displays a set of categories and another screen that lets you add/edit those items. Currently it is very hard to propagate those change events across the boundaries of the screens, because the values are cached in those models and it is hard to find our whether some things are dirty (would have been easy in a traditional web1.0-html-dumb-terminal kind of scenario with serverside declarative caching).
The constructor parameters of the views enable super-easy testing, but without a solid Dependency-Injection framework, one will have some UGLY factory/setup code inside "onModuleLoad()". At the time I started this, I was not aware of Google GIN, so when I refactor my app, I will use that to get rid of this boilerplate. An interesting example here is the "HigherLower" game inside the GIN-Trunk.
I did not get History right the first time, so it is hard to navigate from one part of my app to another. My approach is not aware of History, which is a serious downturn.
My Solutions to those problems:
Use GIN to remove the setup boilerplate that is hard to maintain
While moving from Gwt-Ext to GXT, use its MVC framework as an EventBus to attach/detach modular screens, to avoid the caching/synchronization issues
Think of some kind of "Place"-Abstraction like Ray Ryan described in his talk at I/O 09, which bridges the Event-Gap between GXT-MVC and GWTs-Hitory approach
Use MVP for widgets to isolate data access
Summary:
I dont think one can use a single "MVP" approach for an entire app. One definetly needs history for app-navigation, a eventbus like GXT-MVC to attach/detach screens, and MVP to enable easy testing of data access for widgets.
I therefore propose a layered approach that combines these three elements, since I believe that the "one-event-mvp-system"-solution wont work. Navigation/Screen-Attaching/Data-Access are three separate concerns and I will refactor my app (move to GXT) in the following months to utilize all three event-frameworks for each concerns separately (best tool for the job). All three elements need not be aware of each other. I do know that my solution only applies for GXT-projects.
When writing big GWT apps, I feel like I have to reinvent something like Spring-MVC on the client, which really sucks, because it takes a lot of time and brain-power to spit out something elegant as Spring MVC. GWT needs an app framework much more than those tiny little JS-optimizations that the compiler-guys work so hard on.
Here is a recent Google IO presentation on architecting your GWT application.
Enjoy.
-JP
If you're interested in using the MVP architecture, you might want to take a look at GWTP: http://code.google.com/p/gwt-platform/ . It's an open source MVP framework I'm working on, that supports many nice features of GWT, including code splitting and history management, with a simple annotation-based API. It is quite recent, but is already being used in a number of projects.
You should have a look at GWT Portlets. We developed the GWT Portlets Framework while working on a large HR Portal application and it is now free and open source. From the GWT Portlets website (hosted on Google code):
The programming model is somewhat similar to writing JSR168 portlets for a portal server (Liferay, JBoss Portal etc.). The "portal" is your application built using the GWT Portlets framework as a library. Application functionality is developed as loosely coupled Portlets each with an optional server side DataProvider.
Every Portlet knows how to externalize its state into a serializable PortletFactory subclass (momento / DTO / factory pattern) making important functionality possible:
CRUD operations are handled by a single GWT RPC for all Portlets
The layout of Portlets on a "page" can be represented as a tree of WidgetFactory's (an interface implemented by PortletFactory)
Trees of WidgetFactory's can be serialized and marshalled to/from XML on the server, to store GUI layouts (or "pages") in XML page files
Other important features of the framework are listed below:
Pages can be edited in the browser at runtime (by developers and/or users) using the framework layout editor
Portlets are positioned absolutely so can use scrolling regions
Portlets are configurable, indicate when they are busy loading for automatic "loading spinner" display and can be maximized
Themed widgets including a styled dialog box, a CSS styled button replacement, small toolbuttons and a HTML template driven menu
GWT Portlets is implemented in Java code and does not wrap any external Javascript libraries. It does not impose any server side framework (e.g. Spring or J2EE) but is designed to work well in conjunction with such frameworks.
The context is that I don't want to use Zend MVC - controllers, helpers, decorators etc - that's overkill for what I am writing.
I've scoured the jQuery site plugins section and these issues bother me most:
I have to search a lot for plugins - it is tedious.
I have to check dependencies with jQuery versions. Thankfully I decided to stick with only jQuery or noConflict() would have driven me crazy.
I have to hook-up all the id's and names of form elements across HTML+CSS+JQuery through Controllers, Views etc.
And all this because there is no other simpler PHP wrapper over jQuery plugins than ZendX_JQuery - and plugins is where the attractive scripts and effects are.
Writing a in-house replacement to ZendX_JQuery will be a huge task in itself. But if you have to wrap third party jQuery plugins in PHP and maintain the thing it is full time job in itself.
So I want to know if Zend_Dojo is much easier than ZendX_JQuery. I'm asking before trying out because I'd have to spend a couple more days installing, configuring and testing all the standard Dojo controls and then I can decide. All that's tedious for a rather simple app which may grow later on.
The alternative would be a "jQuery-inside" PHP widget library that is stable and will work for a year without being broken or upgraded.
Something like GWT or ZK or ASP.Net where you don't have to do low-level HTML+jQuery coding and hand-tweaking for every page with all the ajax controls and form elements.
Or should I just drop an MVC framework altogether and replace it with a custom set of scripts only using Zend components where necessary - like Zend_Validate, Zend_Form etc.
I've been working on desktop apps for some time and the switch to AJAX + MVC + Zend is proving a bit too unwieldy, especially given the abundance of design patterns in Zend MVC.
My recommendation would be to use neither ZendX_JQuery or Zend_Dojo. By the sounds of it, that's overkill for you as well. My thoughts may be coloured by the fact that I don't like to mix PHP and JavaScript code except where absolutely necessary - yes, it may be easier to let a component write your JavaScript for you, but it's never going to be as clean as you could write it yourself.
That way, you also maintain separation between behaviour and presentation - always a good thing, as it makes it easier to use the concepts of progressive enhancement.
I agree with Stephen Orr- I use neither jquery nor dojo (after trying both). I use Zend_Form filters / decorators heavily because client side validation has to be redone on the server side anyway. With some custom decorators, you can do it all in html/php.
I try and avoid ajax where possible, and use prototype / scriptaculous where it cannot be avoided. They are lightweight and provide handy shortcuts to use in other JS code.