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