>From: [EMAIL PROTECTED] > > 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. >
Why is the UIViewRoot not a registered component in the faces-config? It seems like there are several hooks in the view root that could be overridden for this type of behavior since the lifecycle starts each phase at the view root. I was thinking about trying to mix view types. Have you looked at allowing Facelets to include a JSP fragment? I was looking at it for clay but it's just not an area that's standardized. My thought was swapping out the view root before the JSP was included and then swapping it back and merging children. Maybe this could be done with a customized ViewRoot? Another use of the ProcessingContext you described. > 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] >
