Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Jacob, Perhaps I'm just a big idiot, or perhaps I don't have enough time in the day to fully explore this whole idea, but I'm still having the same problem I had last time we discussed this issue: "huh?" I don't _get it_ and I won't really until someone can pony up and at least provide some basic sample code that explains through example what the proposed change is. Keeping in mind that many of us know next to nothing about JSF, is there any way you can show us how this would work? For example, would web.xml look different? Would a typical action look different? How about a JSP? If so, how? Sorry, but I really can't commit one way or the other or even provide any insightful comment until I can see what you're suggesting. Thanks! - Posted via Jive Forums http://forums.opensymphony.com/thread.jspa?threadID=25519&messageID=50305#50305 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
My entire thoughts on the EL-API thing is this:
I only care about using the EL API if I get the additional tool support. IDEA,
for example, does some decent code completion when you do ${ ... } in a JSP. It
doesn't, on the other hand, do anything useful when I type or use %{ ... } in another WebWork tag. I see very little value,
other than knowledge transfer of a quite simple language, in using the EL-API
if we can't also take advantage of these tools.
As I understand it, simply plopping in some other underlying EL such as Jexl or
Ognl won't get us any closer to that tool support. Is that correct? My hunch
says that IDEA will, whether it should or not, continue to do code completion
as if the EL was using the standard implementation.
Again: short of slightly simpler "brain matter migration" with the "${" and "}"
tokens in our JSPs, what value does using the EL-API provide when using a
completely different underlying language?
-
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=25519&messageID=50303#50303
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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 strate
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Gary VanMatre wrote: >From: [EMAIL PROTECTED] > > 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 inter rogate 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. This is what I'm doing for JSF Avatar such that a custom UIViewRoot is used to act as a mediator to filtered subsets of the component tree for partial processing over AJAX. UIViewRoot is registered as a component type and is overridable, but global to the application because it falls under the same 'laws' as any other UIComponent. Contractually, I believe we want something similar to UIViewRoot moving forward, but simplified such that it hopefully becomes much easier for other frameworks to implement alternate types of requests. I believe this would cascade through the rest of the UIComponent API such that it would be more conceivable to have a non UIComponent be a parent of something like an ActionComponent or ValidationComponent, retaining the (naked) compositional nature of JSF. So it just comes down to the fact that UIViewRoot is a UIComponent where it would be more flexible to say that a UIComponent would implement a simpler interface (which anyone could-- without being bound to the laws of UIComponents). Overall, the concepts of JSF are *very* simple, we just need to boil the contracts down such that the API becomes much more accessible to other request life cycles, supported by a flexible controller within the spec. > 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 :) > > &g t; >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 & gt; >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 A
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
>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 val
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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
Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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 mode
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Sorry, I meant to type Stripes, not Wicket. Don Michael Jouravlev wrote: On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote: OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others. It is the most advanced EL with the most features, however some of those aren't well documented. Wicket guys switched from OGNL to their own implementation, they say it is much faster though more limited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote: > OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others. > It is the most advanced EL with the most features, however some of those > aren't well documented. Wicket guys switched from OGNL to their own implementation, they say it is much faster though more limited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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). 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. 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. 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
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Don, I wanted to comment on the idea of plugging expression languages into the current code, because as one who has written a lot of the recent type conversion code and delved deeply into OGNL, I would say this is a difficult, though not impossible task. The issue is that all the property accessor classes and method accessor classes that are so integral, are all OGNL related. Removing that would also remove a lot of functionality of XWork. However, it is not impossible. OGNL depends on a language file which generates all of the classes that are used for evaluating an OGNL expression. Knowing the language file is knowing OGNL and being able to modify it. It would then perhaps be possible to create language files in any EL we like, which would then still go through all the property accessors (or method accessors) as we like and handle null properties as well, which would be nice to do independent of EL. Another option, possibly usable in the paragraph above is to make OGNL more like JSTL or a more standard language but 'extend' it. In this option, OGNL would look much like JSTL (which in a lot of ways it already does such as Map, List and property accessing), but using the action taglibraries (the former webwork taglibraries) one would be able to use the extended functionality of OGNL such as method accessors. Since OGNL isn't really in development, we ought to feel free to develop it to our purposes. Just some thoughts to thow out there on a tangential topic. Gabe - Original Message From: Don Brown <[EMAIL PROTECTED]> To: Struts Developers List Sent: Sunday, April 9, 2006 3:07:26 PM Subject: Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF) Sorry, I should be more clear when discussing EL. An Expression Language or EL is a concept I think we all agree is a good thing. Implementations of EL include JSP 2.0, JSF 1.0, the Unified EL, OGNL, Jexl, JXPath, and many others. Struts 1.x used a poor man's EL through Beanutils, which lacked many of the features you now associate with EL. The Unified EL is used by the next JSF and JSP (2.1 I think) with the purpose of unifying the different incarnations of EL they both used. OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others. It is the most advanced EL with the most features, however some of those aren't well documented. My point was first, Action 2 should allow you to plug in any EL you'd like, including the Unified EL, and second, at this point, I don't see the Unified EL replacing OGNL for primarly usage, mainly because the Unified EL lacks several key features, the lack of which is a conscious decision of the working group. Still, I'm sure there will be those Action 2 users who would rather have the familarity of the Unified EL over the advanced features of OGNL, so we hope to make that an option some day. Don Michael Jouravlev wrote: > On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote: > >> 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. >> > > > I see an advantage of unified EL in creating proper names for HTML > input elements and automatic propagation if input data to backing > beans. Basically, this is kind of Struts HTML tags + beanutils + > proper type conversion or WebWork tags + OGNL. Doing it JSF way is > more unified, instead of having different Struts 1, Struts 2 or > Stripes way. This feature is not planned for JSP 2.1, but I think it > can be implemented. Sun pushes JSF and implements new features in JSF > only. > > Michael. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Sorry, I should be more clear when discussing EL. An Expression Language or EL is a concept I think we all agree is a good thing. Implementations of EL include JSP 2.0, JSF 1.0, the Unified EL, OGNL, Jexl, JXPath, and many others. Struts 1.x used a poor man's EL through Beanutils, which lacked many of the features you now associate with EL. The Unified EL is used by the next JSF and JSP (2.1 I think) with the purpose of unifying the different incarnations of EL they both used. OGNL is used by Action 2/WebWork, Tapestry, Wicket, and several others. It is the most advanced EL with the most features, however some of those aren't well documented. My point was first, Action 2 should allow you to plug in any EL you'd like, including the Unified EL, and second, at this point, I don't see the Unified EL replacing OGNL for primarly usage, mainly because the Unified EL lacks several key features, the lack of which is a conscious decision of the working group. Still, I'm sure there will be those Action 2 users who would rather have the familarity of the Unified EL over the advanced features of OGNL, so we hope to make that an option some day. Don Michael Jouravlev wrote: On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote: 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. I see an advantage of unified EL in creating proper names for HTML input elements and automatic propagation if input data to backing beans. Basically, this is kind of Struts HTML tags + beanutils + proper type conversion or WebWork tags + OGNL. Doing it JSF way is more unified, instead of having different Struts 1, Struts 2 or Stripes way. This feature is not planned for JSP 2.1, but I think it can be implemented. Sun pushes JSF and implements new features in JSF only. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
On 4/9/06, Don Brown <[EMAIL PROTECTED]> wrote: > 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. I see an advantage of unified EL in creating proper names for HTML input elements and automatic propagation if input data to backing beans. Basically, this is kind of Struts HTML tags + beanutils + proper type conversion or WebWork tags + OGNL. Doing it JSF way is more unified, instead of having different Struts 1, Struts 2 or Stripes way. This feature is not planned for JSP 2.1, but I think it can be implemented. Sun pushes JSF and implements new features in JSF only. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
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 :) 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. 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. 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... ;) 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
[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]
