Wasn't there an agreement that the tangents would indicate what they were in posts, like [SHALE] or [JSF]. It is difficult enough around here to figure out what is going on without this sort of discussion going on as if it were struts.
On 4/10/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > 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 > > -- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
