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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
