Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)

[jacob]

I really don't know how successful we would be with that approach considering that we'd be offsetting WW phases, separate from UIComponent phases within the controller.  JSF would go through decode, validate, update, then hit the action phase-- where then WW would do the same phases within JSF's lifecycle.  I guess it would be okay, but I think that in relation to what Don is bringing up, it'd be great to get a common lifecycle where both JSF and Actions can co-exist within the same controller instead of a subset of each other.  I really don't see this happening until JSF 2.0 which should be starting up soon :-) Also, there's the case of the threadlocal-- WW has the ActionContext, JSF has the FacesContext.  In some ways, I appreciate the FacesContext a bit more since it already has the Factory/Facade over the Servlet/Portlet APIs with ExternalContext and built-in support for Application delegation and unified-EL.  It's just that UIViewRoot relationship that bothers me since it's a dependency that I don't think everyone wants in terms of model 2/action requests.  Something obviously similar, but slimmed down a bit if possible. Another artifact within the JEE spec that would be a biproduct of JSF 2.0 is common annotations for MVC concerns, such as validations and resource injection.  I hope that Seam's group takes an active role in defining this since much of it is in fact JSF agnostic at this point and could be coordinated within other frameworks today. I still have to take a look at Shale to see how the interceptors/dialogs are handled. -- Jacob

On 4/10/06, Don Brown <[EMAIL PROTECTED]> wrote: 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). In JSF 1.1, the APIs for the EL were indeed tightly bound.  But that's no longer the case with JSF 1.2.  The javadocs for the EL are formally still part of the JSP 2.1 spec, but are implementable separately.  You can grab the spec documents (JSP and EL, bundled in one download) and the javadocs (again, bundled), at:   http://jcp.org/aboutJava/communityprocess/pfd/jsr245/index2.html These are in the "Proposed Final Draft 2" state, in JCP terms, so I wouldn't expect to see much, if any, change before they go final. 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. That (porting Struts-Faces) is a reasonable thing to do.  Not only does it help the developer who just needs a few pages with JSF components (but wants to keep their existing overall architecture), it also helps those who are trying to migrate. 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. A strategy on my TODO list for Shale is to actually go in the other direction, by using JSF extension points to add in the processing of XWork interceptor chains.  The two places this makes sense are: * Overriding the default ActionListener, which actually calls the   action method.  This corresponds to when an action framework   invokes the "execute" or whatever method on the selected action.   This takes care of per-action pipeline customizations. * Supporting the use of an XWork interceptor stack in the application   controler filter part of Shale (as an alternative to the current mechanism,   which lets you customize a Commons Chain command chain).  This   takes care of global pipeline customization. The first scenario seems pretty straightforward.  I don't know XWork well enough to know whether the second strategy can actually be implemented the way I think it should (it would be necessary to split the "before" and "after" parts of the interceptor chain), but that'll become obvious when it gets attempted :-). The gain for the end user is to be able to reuse (or migrate) existing interceptors without having to rewrite everything. This is a good discussion, and I hope it can continue and be a benefit to both communities. Don Craig