> Fundamentally, this is very similar to what we've done with the
EL-API-- Seam,
> Shale, and Spring can all provide behavior from different contexts,
coordinated
> by vistors in the form of ELResolvers which provides a *very*
flexible way of
> mapping back to models within MVC. Now lets do the same for MVC
controllers.
>
> -- Jacob
>
> >Jacob Hookom wrote:
> >> 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.
> >
> >I guess what I'm saying is the navigation is already the way we
want it. What
> >would reimplementing it as a
> >NavigationHandler bring to the table?
> >
> >> 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=true when compiling the grammar.
> >
> >Ok, I was under the impression that the Unified EL was tightly
coupled to the
> >implementation. If the API is abstract
> >enough to handle different implementations such as OGNL, then this
is good
> >news. This might be the abstraction we were
> >looking for to ensure Action 2 isn't tied to one EL. Of course,
deciding to
> >implement the EL API by OGNL is one thing,
> >finding someone with the time and expertise to do it is another :)
> >
&g t; >Do you know of an alternate implementation of the EL API and/or
more
> >documentation about it? In my research, everywhere
> >I saw it mentioned it didn't make the distinction, and comments,
particularly
> >on TSS, seemed to indicate the features I
> >previously mentioned were explicitly rejected (method invocation, for
> >example).
> >
> >Ok, so we can walk away with saying we might be able to collaborate
on the EL
> >API, provided someone steps up and ports
> >OGNL or an EL with a similar set of capabilities to it. I'm still not
> >convinced implementing WebWork as a Lifecycle
> >implementation would bring any value for 95% of the applications,
however, at
> >some point, I am planing on porting Struts
> >Faces to Action 2 for the edge case of a WebWork app that wants to
take
> >advantage of JSF components, the real draw of
& gt; >JSF IMO, for certain pages. At which time, I'll look more into
different
> >integration approaches like this one.
> >
> >I guess the bottom line I think our best bet is to focus on
discrete problems
> >like EL, validation, annotations, etc. for
> >integration. From a framework developer perspective, sharing APIs is
> >interesting, but not so for the end user, who
> >could probably care less. I guess I'm trying to see what advantages
this
> >would bring to the end user. The one
> >capability of JSF that I'd like to use in an Action 2 application,
as an end
> >user, is its stateful components,
> >particularly complex, out-of-the-box components. I'd be interested
to hear of
> >more capabilities an Action 2 developer
> >would get out of such a hybrid.
> >
> >This is a good discussion, and I hope it can continue and be a ben
efit to both
> >communities.
> >
> >Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
