Available JSF MVC components

I'm new to Java-based web programming and am trying to learn JSF from the ground-up. I've heard JSF explained as an entire MVC solution, with Facelets being a开发者_开发问答 pure XML technology comprising the "View" component of the MVC architecture.

So, not knowing any betters, that leads me to ask: what choices/alternatives exist for each component? For each of the 3 (Model, View & Controller), what tools/APIs/libs/technologies exist that will work with JSF. For instance, if understand the View basics correctly, JSP is an (old/obsolescing) alternative to Facelets. Any others? What about the Model component: what are my options there? Controller?

Again, just interested in keeping everything under the JSF umbrella for now: if the component is compatible as some part a JSF solution, I wanna hear about it!

Thanks for any recommendations!

I'm surprised BalusC hasn't hit this one already with one of his sickeningly complete answers. I suspect he'll get around to it, and when he does I'll vote for it because it'll be awesome so don't accept my answer right away. In the meantime, here are some thoughts:

JSF is meant to be the full MVC stack, with the emphasis on VC. You've got JSP/Facelets correct. Simply put, don't use JSP. Use Facelets. They are the default view technology for JSF 2. They are xml based and will keep you from hurting yourself with 'interesting' interactions between the JSF lifecycle and the JSP lifecycle.

You will write java classes and navigation rules to fill the controller role in JSF. You can use JSF managed beans for your services, or you could use some other framework like Spring for that purpose, but you will implement specific classes to be used as the controllers in JSF.

As for the model... well, any good MVC framework will leave the model to itself. A model shouldn't know or care about which view it's in. Hopefully you can take the model and display it in a web page using anything from JSF to Wicket to Vaadin, and then also use it in a desktop app or a RESTful JSON based api.

Here are some links I would suggest you go through to get a handle on JSF

• http://www.ibm.com/developerworks/library/j-jsf1/ (older, but will get the basics down)
• http://www.ibm.com/developerworks/library/j-jsf2/ (part 2 of the above)
• http://www.ibm.com/developerworks/library/j-jsf3/ (part 3 of the above)
• http://www.coreservlets.com/JSF-Tutorial/jsf2/ (Marty Hall's tutorial

I think your understanding is correct.

I'd say that JSF fills most of the part of the controller. There are other libraries that are compatible with JSF though. For example, you can use Spring WebFlow together with JSF to get more powerful navigation features.

JSF is not very intrusive when it comes to the model. Ideally, there aren't any traces that you are using JSF in your domain model (the exception is that JSF provides annotations that you can optionally use, such as @ManagedBean). This means you are free to use any libraries you want. You can use Spring IOC or EJB if you want to, or you can code your entire model in plain old java objects.

That being said, I should like to emphasize that JSP is not obsolete. As digitaljoel points out, Facelets have replaced JSP as the view technology in JSF, but JSP is still alive and healthy in other frameworks. There is not an agreement that JSF including Facelets are "better" than JSP (together with another web framework); and JSF has not become an industry standard.

Writing a web application using JSF is closer to writing a desktop application, since they have abstracted away much of the request-response handling. There is not a specific method being invoked each time a client does a request, instead each request passes through a lifecycle of which you are not fully in control. Interacting directly with the HttpServletRequest is discouraged.

Ignoring the request-response nature of the web increases the complexity of a request and conflicts with another growing trend: rich web applications that heavily relies on Javascript. The responsibility of the view logic is moved from the server to the browser, which interacts with the server using Ajax against thin HTTP APIs.

The point is that JSF is not the end-all framework that you need to learn and ignore everything else. It can be the correct choice for some applications, but not for all.