Hi
I have send a subscribe email to sympa_at_jax-rs-spec.java.net, but it
say the request has been sent to the list owner's for approval. I have
been working around this topic, and I would like to contribute with my
opinions about this, but without any action on that side, I can't do
anything.
After looking the problem in deep I think we need to take some action
on both sides. On JAX-RS, because the ideal is to put a front
controller on top of JSF, but that needs some collaboration between
both frameworks (in a similar way as the portlet integration works).
In JSF, we can provide some improvements, that are just a complement
for JSF existing programming model, but that are inspired into action
source frameworks, and in that way, it could help users to make an
easier integration between javascript and JSF.
regards,
Leonardo
2014-05-23 17:34 GMT+02:00 rajmahendra_at_gmail.com <rajmahendra_at_gmail.com>:
> I am Raj from India, JUG Chennai https://plus.google.com/+JUGChennai/photos
> founder and currently in Hyderabadhttp://www.meetup.com/jughyderabad/ so
> leading JUG Hyderabad.
>
> Its an awesome idea We are love to be part of this new journey :)
>
> On Fri, May 23, 2014 at 8:57 PM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
>>
>> >>>>> 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
>>
>>
>
>
>
> --
>
> Thank you and regards,
> Rajmahendra (Raj)
> JUG Chennai Founder
> JUG Hyderabad Lead
> http://about.me/rajonjava/
> http://www.twitter.com/rajonjava
> ----------------------------------------------------------------------------------------------
> "DREAM is not what you see in sleep;
> is the thing which does not let you sleep" - APJ Abdul Kalam
> Do the difficult things while they are easy and do the great things while
> they are small.
> A journey of a thousand miles must begin with a single step. - Lao Tzu