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
