>>>>> On Fri, 7 Mar 2014 21:42:51 -0500, Leonardo Uribe <lu4242_at_gmail.com> said:
LU> Hi
LU> I think it is necessary to clarify the intention behind this,
LU> because it is possible to identify multiple use cases where this can
LU> be useful.
LU> It is clear that any web application using an action source
LU> framework relies on a template framework to do the view
LU> management. In fact something like Spring MVC or JAX-RS helps to
LU> fill the "controller" gap. The "view" gap can be done in many ways,
LU> being JSP and Thymeleaf very popular among Spring MVC community.
LU> But over the time, people has also found the combination of Spring
LU> MVC and JSF pretty powerful. This is nothing new and it is very
LU> popular. I have found this blog that summarizes the perception of
LU> the users. I'll write the relevant parts for the discussion:
LU>
http://papweb.wordpress.com/2011/07/29/spring-mvc-3-jsf-2-with-maven-2-and-tomcat/
PAP> "...
PAP> - I wanted a combined template and component-oriented approach to view
PAP> construction. Granted, there are numerous different frameworks
PAP> out there that does this, but I wanted to try out JSF 2 as it
PAP> seems to accomplish these things in a fairly easy and concise
PAP> way.
PAP> - I don't care much for the request handling pattern and URL scheme that JSF
PAP> brings with it. Call me conservative, but I like a clean MVC
PAP> pattern with a clear division of roles. Most component-based
PAP> frameworks, in my opinion, blur the lines unduly between
PAP> controller and view. I'm typically not very fond of automagic
PAP> form generation and post-back and the whole "code behind"
PAP> concept that JSF (and Tapestry and ASP.NET and a bunch of other
PAP> component frameworks) use. So, Spring MVC is more my
PAP> style. There are other action-oriented frameworks you can use,
PAP> but Spring MVC is as good as any plus ....
PAP> - Since I prefer to write most of my client-side code myself (using either
PAP> Prototype/Scriptaculous or jQuery), I typically fore go using
PAP> pre-built component frameworks (PrimeFaces et al). In my
PAP> experience, they tend to deliver almost what you want, but never
PAP> exactly. And when you run into situations and cases that aren't
PAP> covered by the framework, you'll start to work against it
PAP> instead of with it, which usually ends up burning more time than
PAP> just doing it yourself.
PAP> ..."
LU> In other words, what the user want is in this case is:
LU> - Take advantage of JSF 2 template system (facelets) and component
LU> model.
LU> - Don't use the JSF lifecycle and use something else that fits.
LU> Let me be clear about this: in my personal opinion it is a nonsense
LU> to take out Facelets from JSF, because Facelets was built as a view
LU> technology that takes advantage of JSF component model. If you take
LU> facelets out of JSF, what you are really doing is get rid of JSF
LU> lifecycle, but besides that, you are not doing anything else. You
LU> still want facelets TagHandlers that build a JSF component tree that
LU> can be manipulated somehow and finally rendered. The very essence of
LU> JSF remains active.
LU> Instead, what we can do is provide something to plug JSF as a view
LU> technology. In Spring MVC there is the concept of a "template
LU> resolver". We could create a Factory or something like that.
LU> Note in this case we could have a two step lifecycle:
LU> * build the view (just like restore view phase, but without state
LU> management)
LU> * render the view
LU> Even JSP has a simple lifecycle similar to this one. But doesn't
LU> this sound familiar? because this is exactly what JSF lifecycle
LU> already does when the first request is processed.
LU> Is the JSF lifecycle really a problem? In my opinion what we really
LU> need to do is "rethink the JSF lifecycle". There are two critical
LU> modifications that could be done in JSF:
LU> * Add a "Front Controller" on top of JSF.
LU> * Provide a way to indicate JSF when to skip certain phases (apply
LU> request values, process validations, update model, invoke
LU> application), according to the user requeriments.
LU> PrettyFaces already provide something similar to a "Front
LU> Controller" on top of JSF. In fact it has two features that are
LU> relevant to the discussion:
LU> * Page-load actions -- Call one or more action-methods, at one or
LU> more phases, before rendering a view.
LU> * HTTP parameters parsed from URLs are stored in managed beans,
LU> simply get a reference to your parameter bean for easy access from
LU> other Java classes.
LU> This is evidence that people has been looking around over this topic
LU> for some time. Maybe it is time to standarize some of the features
LU> of PrettyFaces that points to the problem under discussion.
LU> Another use case that help us to understand better what needs to be
LU> done is think about how the people are mixing HTML + javascript and
LU> JSF. Suppose you want to create an input component that suggest some
LU> options to the user at the time he is writing. So, the user include
LU> some javascript library and he quickly founds that it is necessary a
LU> JSON response to fill the options in the suggestion list.
LU> How to do that in JSF? you need to provide a filter, or a controller
LU> or something that can provide the endpoint and fill the missing
LU> gap. Validation could be relevant or not. You need validation only
LU> when the value is finally submitted, but not before because the user
LU> is entering just a suggestion. So, it could be cases where
LU> validation is important, but it could be other cases where
LU> validation is not important or relevant too, but apply values and do
LU> the conversion is. The HTML markup remains intact.
LU> What's really important here is people also want to preserve the JSF
LU> context and in that way, a view scope bean, or a flow scope bean or
LU> whatever bean in any context you can imagine should keep
LU> working. People wants to keep using managed beans to define those
LU> endpoints.
LU> Please note some users wants an action source framework in JSF,
LU> because they usually found this use case troublesome, and an action
LU> source framework helps to fix the problem, but it only solves the
LU> problem partially, because as soon as you are using that approach,
LU> you loose the context and in that way the streamlined integration
LU> between JSF - Bean Validation - CDI and so on. In some case the
LU> Front Controller doesn't exclude the possibility of execute the JSF
LU> lifecycle partially or fully. Maybe the Front Controller approach is
LU> just something related to the real objective that is provide an
LU> endpoint inside JSF that provides JSON or XML responses.
LU> At last I would like to remind you some statements in the overview of JSF spec
JSF> "... JSF provides ease-of-use in the following ways :
JSF> 1. Makes it easy to construct a UI from a set of reusable UI components
JSF> 2. Simplifies migration of application data to and from the UI
JSF> 3. Helps manage UI state across server requests
JSF> 4. Provides a simple model for wiring client-generated events to server-side
JSF> application code
JSF> 5 Allows custom UI components to be easily built and re-use
JSF> ..."
LU> Nothing has changed. This time, we just need to focus on point 4 of
LU> the list, since we already have done the other points pretty well.
LU> regards,
LU> Leonardo Uribe
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 1 Work Days Til JavaLand 2014
| 31 Work Days til JAX 2014