Great, it sounds like there's an overlap of ideas here :-) Fundamentally, my approach to JSF 2.0 is to continue the CoR patterns with the various application handlers, while sticking to the 5 phases of MVC, allowing other interceptors to provide intermediate processing within those 5 distinct phases.
Secondly, brining in the concept of a ProcessingContext into JSF such that stateful UIComponent requests are only one implementation of the ProcessingContext. The idea of a ProcessingContext with JSF was originally brought up with JSF Avatar, such that a single view/tree could be processed in part or in whole, but the fact that the JSF API was tied to a UIViewRoot object somewhat limited the flexability here. So, if we provide this facade that the controller/listeners/interceptors operate on, much like a WebWork ActionContext, then we can say that JSF and WW are both client implementations that coexist via CoR/interceptors within a single controller. Martin brought up the need for the visitor pattern which could be used in conjunction with phaselisteners/interceptors to introduce additional processing. Now, if we play heavy emphasis on composition within this new ProcessingContext facade, then controller participants can operate, via visitor, on a single node (only a WW Action) or a whole tree of them as with JSF. From the 30,000 foot view, that's what JSF is-- a tree of coordinated Actions instead of a single node, much more powerful IMHO, but adds a bit more overhead. So again, at it's core for JSF 2.0, we refactor FacesContext to instead have a ProcessingContext (shorter name?) instead of a UIViewRoot. The lifecycle/interceptors instead interrogate the ProcessingContext for alternate behavior while allowing those interceptors to pass a visitor to flexibly processing a whole composition of delegate concerns within the request. Fundamentally, this is very similar to what we've done with the EL-API-- Seam, Shale, and Spring can all provide behavior from different contexts, coordinated by vistors in the form of ELResolvers which provides a *very* flexible way of mapping back to models within MVC. Now lets do the same for MVC controllers. -- Jacob >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]
