Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of awiner@gmail.com designates
 64.233.162.200 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=U/pRhxuP1eIQTsMTL7QxxqmPLfrwb7Rqvm5/bMZZlMD0PDdWwhiQ24vpHi8DQhJtPucLzbkuum/7++BUPTJIAsuv8x8xcZY9oAk/jeg/ikLBbNZzVG5uEl7/4K5IxgTOAlIXGU03Yee+TIoG1FG2xu5+VJ20tyJ0Y0PaCUABo4g=
Message-ID: <6dac79b90604100733s697b56f1g375c40e825156f90@mail.gmail.com>
Date: Mon, 10 Apr 2006 07:33:59 -0700
From: "Adam Winer" <awiner@gmail.com>
To: "MyFaces Development" <dev@myfaces.apache.org>
Subject: Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Cc: "Don Brown" <mrdon@apache.org>, "Craig McClanahan" <craigmcc@apache.org>,
	"Struts Developers List" <dev@struts.apache.org>
In-Reply-To: <44398ADC.8080200@hookom.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <2387fbc50604091037l7fd5a083k50af49e8ef8ed340@mail.gmail.com>
	 <443950F1.2000003@apache.org> <44398ADC.8080200@hookom.net>

On 4/9/06, Jacob Hookom <jacob@hookom.net> wrote:
> Don Brown wrote:
> > Yeah, I read that post, and while interesting, I'm not sure it would
> > hold much value, particularly for Action 2 applications.
> >
> > Basically, the approach intercepts the usual Faces processing at the
> > start, turning the lifecycle into one used by Action 1.  Action 2,
> > based on WebWork, doesn't have a predefined workflow process, leaving
> > that job up to interceptor chains.  This allows you to customize the
> > completely workflow for a single action or groups of actions (called
> > packages).  In fact, you could argue that perhaps JSF should be
> > implemented as Action 2 interceptors :)
> That's one of the things that I wish the original JSF 1.0 API would've
> done instead of before/after.  Probably just a continuation of the JSP
> stuff that no one likes (which also screwed up JSF's UIComponent API).
> Hopefully in JSF 2.0, we can move to the filter/interceptor pattern with
> phaselisteners (equiv WebWork interceptors).

Trivia/history: the reason JSF didn't use a filter approach was
the inability of JEE 1.3 filters to execute in response to a forward.

> > The two advantages mentioned, navigation and EL, are debatable.
> > Action 2 uses Results, allowing for each action to specify one or more
> > results which could be a simple JSP forward, a Velocity template, or
> > even a Jasper reports.  As I understand JSF navigation, the results
> > are simple request dispatches, harking back to Action 1-type
> > functionality.
> The NavigationHandler has that default behavior. But much like WebWork
> allows the pluggable ActionMapper, all parts of JSF are pluggable in
> that manner.  Seam and SWF are two examples of plugging in alternate
> logic for navigation handling.  So the emphasis is put on the API, not
> the implementation.

Exactly - and this is an example of an area where JSF could
benefit from WebWork - an alternative NavigationHandler
that supports all of the alternative, not-just-a-RequestDispatcher-call
capabilities there.

> > Using EL, on the other hand, I personally don't see as a great
> > benefit.  The new unified EL lacks many of the key features that makes
> > EL and OGNL in particular, so attractive.  For example, OGNL supports
> > method invocation, type conversion, and projection, features, AFAICT,
> > aren't supported by EL and won't ever be.  Still, one of our goals in
> > Action 2 is to make the EL pluggable, so in the future, developers can
> > choose between the unified EL and OGNL, and perhaps other options.
> I've been trying to get everyone behind the EL-API.  The 'traditional'
> EL implementation provided in the spec is, again, only one
> implementation.  The JEXL implementation of the EL-API would be a piece
> of cake, OGNL wouldn't be that hard either if they would use JavaCC with
> the visitor=3Dtrue when compiling the grammar.
>
> So when you say '... aren't supported by EL and won't ever be.' that's a
> lot of smoke up ....  Anyways, the EL-API is what counts here and just
> like JSE 6 has that Script API, JEE has the EL API with semantics that
> fit event based frameworks, such as UIs.  MethodExpressions are a great
> example, along with EL's pluggable ELResolver system such that any
> custom type, converter, logic, etc, can be plugged in to resolve the
> behavior of a.b or a[b].  In terms of OGNL or JEXL, you can go one step
> further and produce a OgnlExpressionFactory or JexlExpressionFactory, as
> so *many* frameworks can take advantage of a common API.  There's also
> talk of having an EL JSR that will roll in everything else people are
> looking for.

I agree with Jacob - an OGNL implementation of an ExpressionFactory
would be an excellent thing.  I'm kinda tired of hearing how a webapp
framework is great or awful because the underlying EL it uses is great
or awful, when the EL implementation should be decoupled from the
framework.

-- Adam


> >
> > The only advantage I can see of this approach is to allow developers
> > to write backing beans, using the same FacesContext as other pages
> > that fully use JSF, but even then, Action 2 actions are POJO's and
> > support arbitrary method invocation already, so the remaining
> > advantage would be the FacesContext consistency.
> >
> > I'm not a JSF expert, so perhaps I'm missing something big.  I still
> > see the areas ripe for collaboration are annotations and efforts to
> > make JSF backing beans and Action 2 Actions useable in both
> > frameworks.  Also, I was only half kidding about implementing JSF as
> > Action 2 Interceptors... ;)
> That's exactly what I'm hoping for with the EL API-- such that we can
> share ELResolvers for handling common validation/converter metadata.
> I'll agree that if JSF's controller wasn't bound to the concept of a
> stateful component model, that it would make a lot more sense as a
> common platform for frameworks.  In JSF 2.0, I hope to introduce the
> idea of a common controller that will support model 1 and model 2 by
> putting the view/state into a facade.  This facade can be implemented as
> a Action in WW terms or a UIComponent tree in JSF terms.  Even if we do
> correct the model 1 in a hybrid implementation, there will always be a
> need for true model 2 support, it's just a matter of how efficiently we
> can integrate the two into a common mind share within JEE.
>
> -- Jacob
>
> >
> > Don
> >
> >
> > Sean Schofield wrote:
> >> [Moving this aspect of the discussion from myfaces to struts list ...]
> >>
> >> On 4/7/06, Jacob Hookom <jacob@hookom.net> wrote:
> >>
> >>> Covered here a bit:
> >>>
> >>> http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.=
html
> >>>
> >>>
> >>
> >> @Jacob:
> >>
> >> Great blog entry!
> >>
> >> @ Struts Dev:
> >>
> >> I recommend you check this out.  Jacob outlines how its possible to
> >> create a simple action oriented framework on top of the JSF API
> >> without fussing with components.    You really get a sense for how
> >> powerful (and pluggable) the API really is.
> >>
> >> Maybe this a possible Action/Shale/MyFaces cooperation opportunity?
> >> Maybe the Webwork stuff could take advantage of the EL and
> >> NavigationHandler?  Its not 100% JSF but it would bring the
> >> Action/Shale frameworks a little closer together.
> >>
> >> Back at ApacheCon USA we talked about trying to work more closely
> >> between the two frameworks.  To me, this idea has some interesting
> >> possibilities.  I know there was some interest in the Shale dialog
> >> stuff but why not get the impressive navigation and EL capabilities of
> >> JSF for free?
> >>
> >> Sean
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> >
>
>
> --
> --------------------------
> Sent from my FrankenBerry Wireless Handheld
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org