>>>>> On Fri, 23 May 2014 10:10:21 -0400, Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com> said:
SPG> I'm the spec lead for JAX-RS and Ed asked me to pop in here and
SPG> invite you over to the mailto:users_at_jax-rs-spec.java.net where we
SPG> are planning to have our discussions. I'd like to preserve the
SPG> momentum from the thread that was started by Arjan back in February
SPG> [2] and had discussions through until April [3]. Our plans for
SPG> JAX-RS MVC include using Facelets and JSP as well as support for
SPG> Flows, ViewScope and FlashScope. Ed will have more to say about the
SPG> JSF side of these things.
Hi Santiago,
Thanks for the invitation.
This email is a call to action to those of us how contributed to the
discussion of MVC on users_at_javaserverfaces-spec-public list.
Specifically, I'm counting on Arjan Tijms, Adrian Gonzalez, Andy Bosch,
Kito Mann, Leonardo Uribe, Manfred Riem, Neil Griffin, and
Frank Caputo to strongly consider joining users_at_jax-rs-spec.java.net and
continuing the discussion there.
Here is a brief summary the discussion that happened on
users_at_javaserverfaces-spec-public thus far, staring with Arjan's message
on Fri, 28 Feb 2014 23:14:52 +0100 [1] and completing with Leonardo's
last message on the thread at Tue, 8 Apr 2014 18:22:44 +0200 [2].
Arjan pointed out the work Manfred did to build the action oriented
framework on top of the JSF lifecycle mechanism.
Adrian Gonzalez wrote:
AG> Both JAX-RS and JSF miss some features for a MVC framework. JSF
AG> misses (at least) the following stuff to support reasonably well the
AG> MVC scenario :
AG> 1. it doesn't support for now HTTP REST usage : HTTP PUT, POST
AG> (without postback), DELETE, etc... This is a blocker.
AG> 2. templating : plugging in a 3rd party templating engine easily
AG> should be supported in MVC.
AG> This is not the case for a component and an action based
AG> framework. As I recall, Spring MVC has been built after
AG> JAX-RS. Spring MVC authors didn't used JAX-RS because it was too
AG> limiting for them . Perhaps someone should ask them why JAX-RS was
AG> too limiting in order to lift those limitations ?
AG> As for PlayFramework, I didn't used it, but here are some goodies :
AG> * code reloading - a must have !
AG> * view are compiled so you can use them in the controllers (to
AG> populate the view and to navigate to them).
AG> * view templates (and form helpers) are more succinct/understandable
AG> than the same in JSP / facelets.
Andy Bosch wrote:
AB> Of course I am in favour of enhancing JSF according to user
AB> feedback. But I am not sure whether it is a good idea to integrate
AB> too much into it.
Ed Burns wrote:
EB> I'd like to see us extract Facelets from JSF, make it a first class
EB> citizen of a JAX-RS MVC, *and* provide an Action Oriented
EB> lifecycle as an alternative to the standard JSF lifecycle.
Andy Bosch replied:
AB> In my personal opinion it sounds good. But I often hear complaints
AB> of people about the JSF lifecycle (mostly those people do not like
AB> JSF at all ;-) ). Some people just don't like a complex
AB> lifecycle. They prefer having a simple controller that is called
AB> during an action invocation.
AB> So to sum up I would say we have to carefully think about how
AB> complex or easy such an lifecycle would become.
Kito Mann asked:
KM> Ed, what's your motivation for doing the JAX-RS route _and_ the JSF
KM> route? Support action-based scenarios within JSF apps, but provide
KM> JAX-RS for those who don't use JSF?
Ed Burns replied:
EB> Right, it's about making Facelets available outside of JSF because
EB> templating is useful on its own, even without the JSF lifecycle.
Leonardo Uribe responded by asserting that the combination of Spring MVC
*and* JSF can be powerful, citing a blog entry and examples.
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.
Leonardo further asserts it is nonsense to take Facelets out of JSF:
LU> If you take facelets out of JSF, what you are really doing is get
LU> rid of JSF lifecycle, but besides that, you are not doing anything
LU> else.
Frank agreed with Leonardo's assertion.
Though I agree with all of Leonardo's other points in his response, I
disagree with this one. You are getting all the page templating from
the <ui:> tag library which doesn't exist in any other server side java
solution aside from Struts Tiles.
Leonardo goes on to sketch a solution to allow JSF to plug more cleanly
into Spring MVC, providing specific details about how the JSF lifecycle
can be improved in the process.
Taking another perspective on the matter, Leonardo outlines the
data-only JSF lifecycle idea we've been kicking around for years and
discussed at Javaland. The basic idea is to have a way for a JSF ajax
request to have access to all JSF features except those relating
directly to a view. This would include FacesContext, Flash, Flow, etc
but would *NOT* include anything to do with a specific view. This is
captured in JAVASERVERFACES_SPEC_PUBLIC-1261 and I want to pursue this
in JSF 2.3.
The discussion continued after Javaland. Frank sketched out how you
could forward from JAX-RS to the FacesServlet today, even without Jersey
MVC. Leonardo replied,
LU> The only flaw I can see is using ExternalContext there is no way to
LU> know when the request is a GET, a POST and so on, which is important
LU> at the time to define the endpoint.
LU> Now, it could be useful to have a "action source framework"
LU> component. That means, an special component that work in a way that
LU> everything inside it works just like any action source framework,
LU> but everything outside the box still work under JSF rules.
LU> So, other people has already thought the same as we are trying to do
LU> and have been doing (JSF 2.2 viewAction and JSF 2.0 viewParam),
LU> there are some cases where an action oriented approach with a
LU> component oriented framework can coexist. In that sense, the ability
LU> to define REST services inside CDI managed beans through Faces
LU> Servlet seems to be important. For what? It is not hard to find
LU> cases. For example, to expose information to some other app or
LU> component or service that consume it as a REST service. If you have
LU> a JSF webapp nothing can be simpler as define the method right on
LU> the managed bean.
Leonardo followed up on this with some very detailed suggestions.
Leonardo, please join the discussion over on
users_at_jax-rs-spec.java.net. He ends by summarizing:
LU> For some users who currently uses JSF at a daily basis, this problem
LU> is not something important, because there is a workaround and this
LU> usually suppose a small part of the whole application, so you don't
LU> really spent a lot of time solving it. It is not really hard to
LU> write a couple of servlets that can do the job in these cases.
LU> But for some other users that are not into JSF, this is
LU> important. The reason is JSF Template engine (Facelets) solves a lot
LU> of problems for them. These guys usually are making applications
LU> with another architectural paradigm, different to the one proposed
LU> initially by JSF.
Let's get moving!
Ed
[1]
https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-02/message/7
[2]
https://java.net/projects/javaserverfaces-spec-public/lists/users/archive/2014-04/message/6