myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Don Brown <mr...@apache.org>
Subject Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Date Mon, 10 Apr 2006 19:48:06 GMT
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 :)

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 
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 benefit to both communities.

Don

Mime
View raw message