users@jax-rs-spec.java.net

[jax-rs-spec users] Re: [jsr344-experts mirror] JAX-RS MVC

From: Frank Caputo <frank_at_frankcaputo.de>
Date: Tue, 27 May 2014 19:52:28 +0200

Hi,

Iím Frank Caputo and happy to continue the discussion here.

Ciao Frank

Am 23.05.2014 um 17:27 schrieb Edward Burns <edward.burns_at_oracle.com>:

>>>>>> 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
>
>