I am trying to get familiar with Java EE 6 by reading http://java.sun.com/javaee/6/docs/tutorial/doc/gexaf.html. I am a bit confused about the use of JSF.
Usually, the way I develop my Web App would be, Servlet would act like a controller and JSP would act like a View in an MVC model. So Does JSF try to replace this structure? Below are the quote from the above tutorial:
Servlet are best suited for service-oriented App and control function of presentation-oriented App like dispatching request
JSF and Facelet are more appropriated for generating mark-up like XHTML, and generally used for presentation-oriented App
Not sure if I understand the above quote too well, they did not explain too well what is service-oriented vs presentation-oriented.
A JavaServer Faces application can map HTTP requests to component-specific event handling and manage components as stateful objects on the server.
Any knowledgeable Java developer out there can give me a quick overview about JSF, JSP and Servlet? Do I integrate them all, or do I use them separated base on the App? if so then what kind of app use JSF in contrast with Servlet and JSP
A JavaServer Faces application can map HTTP requests to component-specific event handling and manage components as stateful objects on the server.
Sound like what servlet can do, but not sure about manage components as stateful objects on the server. Not even sure what that mean? Thanks in advance.
JSF basically enables you to develop a web application with only model objects (JavaBeans) and views (JSP/XHTML pages). With "plain vanilla" JSP/Servlet you'll have to bring in a lot of code to control, preprocess, postprocess, gather data, validate, convert, listen, etc the HTTP request and response. And then I'm not talking about refactoring it to a high (abstract) degree so that you can also end up the same way as JSF does (just a JavaBean class and a JSP/XHTML page per use case).
I've posted a more detailed answer on the subject before here: What is the difference between JSF, Servlet and JSP?
In JSF uses one specific Servlet (the Faces Servlet) to handle all incoming requests and dispatch them to the appropriate beans.
JSF is a component-based MVC framework, while JSP is a view technology.
You can use JSP with JSF, although Facelets is the preferred view technology.
JSF provide an abstraction layer with several responsibilities, but most important it handles all the messy details of HTML forms and transferring data back and forth between web pages and Java POJO beans (getX, setX methods), which is notoriously difficult to do right.
It also provides navigation and in the latest incarnation in Java EE 6 rudimentary AJAX support is available allowing for simple updates of the web page as the user inputs data.
You might find it easier to think of it as a way to avoid writing JavaScript yourself.
If you like XML choose JSF. In case that you are an actionlistener fan
doPost,doGet etc choose Servlet and JSP.
JSF Framework targets to simplify development integration of web-based user interfaces. As #bozho stated you can mix JSP and JSF. However, the "view" component in JSF is facelets - which can be viewed as little UI widgets, which are more or less self contained with respect to DHTML styling and JavaScript event generation and call back.
"Should I bother learning.. ?"
Not sure. I haven't seen JSF picking up that much steam even though it was around (Atleast in theory) for last 5 years.
Related
When a user hits a particular internal URL I need to return some html that is created dynamically.
Some back end services will be called to genrated a list of keys which is then used to generated a list of html
href links which are displayed to the user.
For this I am considering using a servlet. Is this a good methodology ?
Since servlets have been around for some time maybe there are newer/better ways of implementing this ?
There are tons of solutions, most of them (in Java) being based on the servlet API. If you use Spring already, Spring has a module called Spring MVC, which is a framework based on the servlet API to create web applications, based on the MVC pattern:
Model holding the data from the database
View (implemented, most of the time, using JSPs) generating markup based on the data contained in the model
Controller getting the data from the database, and dispatching to the appropriate view
This is a good pattern used by most web frameworks, but every one has its own way of doing, strengths and weaknesses.
You could do with a simple servlet, but generating markup from a servlet is ugly. That's why servlets are usually used in combinations with JSPs, following the MVC pattern. You could implement a micro-MVC framework by yourself, using only servlets and JSPs, but Spring-MVC and other frameworks offer so many additional advanteges that the investment is worth it. I personally like Stripes very much, and it's very simple.
Servlets are the Java way of exposing simple interfaces for HTTP request.
This can also be achieved by a REST framework like Jersey, but its a bit more complicated, so if you need a simple one opertaion interface, I'd go with servlets.
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.
I'm trying to choose an AJAX-friendly Java framework for my first web application and am interested in first
understanding the architectural differences between the different flavors that are out there.
I like the concept of MVC frameworks, and so am primarily considering the following:
Any JSF variety (ICEFaces, RichFaces, PrimeFaces, etc.)
Spring Web Flow
ZK
Wicket
I've downloaded each of these projects and tried to follow their samples/tutorials, and there is
so much information to ingest I figured I'd take a breather and come here to cover some preliminaries
first.
I'm interested in how each of these frameworks implements the MVC pattern. Obviously, something rooted
in JSF (like ICEFaces) is going to have a different architecture than Spring. I'm sure that this is a
huge question, so I'm not looking for a full-blown tutorial on each of these frameworks; I'm just
curious as to what sort of artifacts (Java sources, XML config files, etc.) a developer has to write in
order to build a single AJAX-driven page using these. I'm interested in the differences to their approach,
nothing more.
For instance, I would imagine that each framework at some point uses a FrontController (or its likes) to
map HttpRequests to the right Controller implementation. That Controller (bean) would then need to do
some processing, possibly hit the database for some information (using ormapping and forming the Model), and
then construct a View/HttpResponse to send back to the client. This is an oversimplification I'm sure, but
there has to be an easy way to explain the high-level architecture for how each of these frameworks accomplishes
that.
Struts uses the ActionServlet (with Struts2 now its just Action) as the controller and model and jsp is the view.
For Spring MVC is achieved by DispatcherServlet which does the routing and Model is not bound to any framework related object you can use any.
JSF - UI jsp or jsf itself, Model - ManagedBean, Controller - FacesServlet.
I did some similar search for my own project a while ago, have a look at the links below:
Comparison based on multiple parameters : http://static.raibledesigns.com/repository/presentations/ComparingJavaWebFrameworks.pdf
Difference between JSF and Struts
http://struts.apache.org/2.0.14/docs/what-are-the-fundamental-differences-between-struts-and-jsf.html
Somewhat related post
https://stackoverflow.com/questions/7633583/which-mvc-is-better-spring-or-struts
Spring and JSF
http://blog.springsource.org/2007/04/21/what-spring-web-flow-offers-jsf-developers/
Spring MVC : http://static.springsource.org/spring/docs/2.0.x/reference/mvc.html
Best Fit For JSF Component Library: Primefaces based on my own experience
From IBM Clearing the FUD : http://www.ibm.com/developerworks/library/j-jsf1/
Hope this gives you some insight.
Have a look at Matt Raible's talk on Comparing JVM Web Frameworks here. You can also consider looking at Spring MVC and 'Tapestry`.
Also, this link gives you a matrix on capabilities of various java web frameworks.
You should also check out the Play framework. I have used it a little and really like it.
It is very easy to get started with minimal configuration (reminds me of Rails).
http://www.playframework.org/
I'm building a JS client and want to be able to quickly test stuff locally during development. I need a mocked server for that.
Since I'm using Maven and its Jetty plugin, I easily got a servlet up that sends responses. Now I would like to slightly improve on this by adding JSP for the view.
I'm already familiar with Struts (and Wicket), but since JSP and Servlet support is already built into Jetty, I thought I could just throw some servlets and some JSPs in there, connecting them with configuration (in the web.xml?) without resorting to a major framework.
Googling so far brings me only general architecture and specification stuff or Struts examples.
JSPs are servlets. So everything you do in a servlet can be done in a JSP directly (or nearly everything).
It's however a bad practice to put Java code into JSPs. So you might just use servlets for the controller logic, and then use request.getRequestDispatcher("/somePage.jsp").forward(request, response) to dispatch the request and response to the JSP. That's the absolute minimum an MVC framework does.
More explanation of servlet basics, inclusing some example code and further links on the wiki page for the servlets tag.
It's unclear what you expect from your minimal framework. But using a framework like Stripes, for example, is pretty straightforward and does all this for you, by adding some lines in the web.xml and some annotations in Action classes replacing the servlets as controllers.
Are their any good websites (characterized by high usage), that use JSF for their back-end? I have just started working with the basics of the framework. If I see some websites using JSF, may be I will be able to better appreciate the use of the technology.
Also could you mention the benefits of using JSF validation viz a viz the browser side validation of content using JavaScript.
See here for a list of JSF sites.
In addition see the references for two famous JSF component frameworks:
Richfaces
Icefaces
As for the validation - it better be on both sides - on the client side (javascript) for better usability, and on the server side for better security.
ebay, volvo, bmw, costco, TNT, Lufthanza and thousands of more websites use JSF for complete or parts of their websites in production.
Check your answer at http://www.primefaces.org/whouses. (Who uses primefaces.) Primefaces is JQuery based UI component library for JSF and is one of the most popular UI Libraries in JSF.
Whoever runs Primefaces , runs on JSF.
You can also check presentation on ebay supplier portal about how ebay uses JSF to achieve scalability and performance. Search on youtube for "eBay, Connecting Buyers and Sellers Globally via JavaServer Faces" (Oct 2014)
The presentation in PDF format is here: https://oracleus.activeevents.com/2014/connect/fileDownload/session/DB08F809615ABF16F149FEC02B892C10/CON2892_Paulsen-J1eBaySelling.pdf
On the validation questions:
Server side Advantages:
Most common validation rules can be declaratively specified i.e. validation rules are specified in tag attributes. Since there is very little code written, this is highly maintainable
For the rest of the validation rules, one can write custom Validator implementations. These implementations (unlike custom components) are straight forward. Although they are more work than declarative validation, but still more maintainable than the JavaScript approach.
Server side Dis-advantages:
Usability is the biggest issue here. Any validation failures can be reported only when the complete HTML form is submitted (not when the value is keyed in). In JSF 2.0 this downside can be overcome by making ajax calls to your validation logic and reporting failures as values are keyed in
JavaScript Advantages
Usability - as detailed above - can report failures as values are keyed in
JavaScript Disadvantages
Even with JS libraries like jQuery, it can be pretty difficult to implement and maintain js code that supports all browsers. Adding support to a new browser can be very expensive.
All data required to complete validation must be pre-loaded when the response is rendered. Whereas in the server side approach the validation code can lookup any data it needs.