On 4/9/06, Jacob Hookom <[EMAIL PROTECTED]> wrote: > Don Brown wrote: > > Yeah, I read that post, and while interesting, I'm not sure it would > > hold much value, particularly for Action 2 applications. > > > > Basically, the approach intercepts the usual Faces processing at the > > start, turning the lifecycle into one used by Action 1. Action 2, > > based on WebWork, doesn't have a predefined workflow process, leaving > > that job up to interceptor chains. This allows you to customize the > > completely workflow for a single action or groups of actions (called > > packages). In fact, you could argue that perhaps JSF should be > > implemented as Action 2 interceptors :) > That's one of the things that I wish the original JSF 1.0 API would've > done instead of before/after. Probably just a continuation of the JSP > stuff that no one likes (which also screwed up JSF's UIComponent API). > Hopefully in JSF 2.0, we can move to the filter/interceptor pattern with > phaselisteners (equiv WebWork interceptors).
Trivia/history: the reason JSF didn't use a filter approach was the inability of JEE 1.3 filters to execute in response to a forward. > > The two advantages mentioned, navigation and EL, are debatable. > > Action 2 uses Results, allowing for each action to specify one or more > > results which could be a simple JSP forward, a Velocity template, or > > even a Jasper reports. As I understand JSF navigation, the results > > are simple request dispatches, harking back to Action 1-type > > functionality. > 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. Exactly - and this is an example of an area where JSF could benefit from WebWork - an alternative NavigationHandler that supports all of the alternative, not-just-a-RequestDispatcher-call capabilities there. > > Using EL, on the other hand, I personally don't see as a great > > benefit. The new unified EL lacks many of the key features that makes > > EL and OGNL in particular, so attractive. For example, OGNL supports > > method invocation, type conversion, and projection, features, AFAICT, > > aren't supported by EL and won't ever be. Still, one of our goals in > > Action 2 is to make the EL pluggable, so in the future, developers can > > choose between the unified EL and OGNL, and perhaps other options. > 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. > > So when you say '... aren't supported by EL and won't ever be.' that's a > lot of smoke up .... Anyways, the EL-API is what counts here and just > like JSE 6 has that Script API, JEE has the EL API with semantics that > fit event based frameworks, such as UIs. MethodExpressions are a great > example, along with EL's pluggable ELResolver system such that any > custom type, converter, logic, etc, can be plugged in to resolve the > behavior of a.b or a[b]. In terms of OGNL or JEXL, you can go one step > further and produce a OgnlExpressionFactory or JexlExpressionFactory, as > so *many* frameworks can take advantage of a common API. There's also > talk of having an EL JSR that will roll in everything else people are > looking for. I agree with Jacob - an OGNL implementation of an ExpressionFactory would be an excellent thing. I'm kinda tired of hearing how a webapp framework is great or awful because the underlying EL it uses is great or awful, when the EL implementation should be decoupled from the framework. -- Adam > > > > The only advantage I can see of this approach is to allow developers > > to write backing beans, using the same FacesContext as other pages > > that fully use JSF, but even then, Action 2 actions are POJO's and > > support arbitrary method invocation already, so the remaining > > advantage would be the FacesContext consistency. > > > > I'm not a JSF expert, so perhaps I'm missing something big. I still > > see the areas ripe for collaboration are annotations and efforts to > > make JSF backing beans and Action 2 Actions useable in both > > frameworks. Also, I was only half kidding about implementing JSF as > > Action 2 Interceptors... ;) > That's exactly what I'm hoping for with the EL API-- such that we can > share ELResolvers for handling common validation/converter metadata. > I'll agree that if JSF's controller wasn't bound to the concept of a > stateful component model, that it would make a lot more sense as a > common platform for frameworks. In JSF 2.0, I hope to introduce the > idea of a common controller that will support model 1 and model 2 by > putting the view/state into a facade. This facade can be implemented as > a Action in WW terms or a UIComponent tree in JSF terms. Even if we do > correct the model 1 in a hybrid implementation, there will always be a > need for true model 2 support, it's just a matter of how efficiently we > can integrate the two into a common mind share within JEE. > > -- Jacob > > > > > Don > > > > > > Sean Schofield wrote: > >> [Moving this aspect of the discussion from myfaces to struts list ...] > >> > >> On 4/7/06, Jacob Hookom <[EMAIL PROTECTED]> wrote: > >> > >>> Covered here a bit: > >>> > >>> http://weblogs.java.net/blog/jhook/archive/2006/03/the_new_servlet_1.html > >>> > >>> > >> > >> @Jacob: > >> > >> Great blog entry! > >> > >> @ Struts Dev: > >> > >> I recommend you check this out. Jacob outlines how its possible to > >> create a simple action oriented framework on top of the JSF API > >> without fussing with components. You really get a sense for how > >> powerful (and pluggable) the API really is. > >> > >> Maybe this a possible Action/Shale/MyFaces cooperation opportunity? > >> Maybe the Webwork stuff could take advantage of the EL and > >> NavigationHandler? Its not 100% JSF but it would bring the > >> Action/Shale frameworks a little closer together. > >> > >> Back at ApacheCon USA we talked about trying to work more closely > >> between the two frameworks. To me, this idea has some interesting > >> possibilities. I know there was some interest in the Shale dialog > >> stuff but why not get the impressive navigation and EL capabilities of > >> JSF for free? > >> > >> Sean > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > >> > > > > > > > -- > -------------------------- > Sent from my FrankenBerry Wireless Handheld > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
