How is this difficult with JSF?
Totally possible with JSF 2.
Possible, but better with an add-on like PrettyFaces.
Hi,I just want to share some thoughts about JAX-RS vs JSF and why in my opinion adding MVC support to JAX-RS is a good idea. We had a small debate on DZone whenever evolving the JAX-RS standard beyond just REST APIs would be a bad or good move:Henk De Boer said that:
Having two MVC web frameworks would IMHO be highly confusing. I know it's popular to bash JSF, but it's actually quite a good framework these days. I wonder if some of this bashing isn't just coming from the people behind the other frameworks (like Wicket and Spring MVC). If JSF's main problem is that it's being blackened by its competitors, why would a new web framework from Oracle/Java EE not receive the same treatment?Instead of having two competing MVC web frameworks within Java EE, it's probably better to give JSF more "action/request"-based properties, for those use-cases that need this. In fact, this is already happening a bit. JSF 2.2's view action is an example of this direction, and the issue about a stateless mode is the most popular one now at the spec Jira. See JAVASERVERFACES_SPEC_PUBLIC-1055.I totally disagree with the above point of view.JSF is a Component-based MVC framework.JAX-RS/MVC is not component-based and it is more suitable in many situations.I was evaluating the two technologies for my last project. My requirements ware:
- easy SEO
- human readable URLs
- front-end based on prototypes written by pure HTML/JS developersJSF is totally unusable in this scenario. And this scenario IS very common in development of content driven sites. JSF sucks in this ares, its good for pure web applications.As for Jersey JAX-RS + their MVC + JSP the experience of developing content driven sites is great.(PS. I know there are hacks and libraries to make JSF fit more to my requirements but its a over-kill compared to JAX-RS MVC)To me it would be a bad decision to leave Java EE with no standard solution for this common scenario.BTW for me the best way the JSF and JAX-RS MVC standards should go is:
- Decouple Facelets from JSF and even HTTP to make it a general XML/STML templating language. Almost every web applications sends HTML emails for example and we have no standard way to generate them.
- Make Facelets an option in JAX-RS MVC.
- Make a clear distinction in the documentation that JSF is best suited if you mostly need a uniform and rapid way to create component based GUIs for web applications. JAX-RS MVC is best suited for content driven websites where you want more control over the HTTP protocol, URL, HTML and JS and you don't need a big abstraction layer over them like JSF.
- If we would take this direction I think we could even call JSP and JSTL deprecated. At least from my point of view I would have no reason to use them.In summary
I hope this will bring on some discussion that will impact Java EE 7 or 8. For me the standard gives no productive API to develop content driven web sites which are a large part of the web. Servlets/JSP/JSTL are a little rusty. JSF gives you much but cannot deal with many common requirements.JAX-RS with MVC is a great verbose API for devs that must have control on the HTTP/HTML/CSS/JS side and don't need a big abstraction layer for their components.--
+48 604 188 992
[javaee-spec users] Re: [JAX-RS vs JSF] Why having two web app frameworks is not a bad thing