You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Sean Schofield <se...@gmail.com> on 2006/04/09 19:37:52 UTC
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 <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[OT] Re: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by James Mitchell <jm...@apache.org>.
Maybe someone should combine everything just to make us happy!!!
shwatt (SHale/Wicket/Action2/Tapestry/Tiles) - It's about choice!
strapon4j (STRipes/Action2/PythON) - Not for the timid!
--
James Mitchell
P.S. Sorry - Friday was too long of a wait!
On Apr 9, 2006, at 2:59 PM, Dakota Jack wrote:
> Why would we want the Action/Shale frameworks closer. I thought
> you guys
> were into diversity, not just trying to sell JSF? Lord, if you
> bring Shale
> to WebWorks, then you will truly have destroyed any hope of Struts
> survival
> in any form, even WebWorks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Dakota Jack <da...@gmail.com>.
Why would we want the Action/Shale frameworks closer. I thought you guys
were into diversity, not just trying to sell JSF? Lord, if you bring Shale
to WebWorks, then you will truly have destroyed any hope of Struts survival
in any form, even WebWorks.
On 4/9/06, Sean Schofield <se...@gmail.com> wrote:
>
> [Moving this aspect of the discussion from myfaces to struts list ...]
>
> On 4/7/06, Jacob Hookom <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Dakota Jack <da...@gmail.com>.
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 <cr...@apache.org> wrote:
>
> On 4/10/06, Don Brown <mr...@apache.org> 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~
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Dakota Jack <da...@gmail.com>.
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 <cr...@apache.org> wrote:
>
> On 4/10/06, Don Brown <mr...@apache.org> 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~
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Craig McClanahan <cr...@apache.org>.
On 4/10/06, Don Brown <mr...@apache.org> 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
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Craig McClanahan <cr...@apache.org>.
On 4/10/06, Don Brown <mr...@apache.org> 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
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Don Brown <mr...@apache.org>.
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Adam Winer <aw...@gmail.com>.
On 4/9/06, Jacob Hookom <ja...@hookom.net> 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 <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> >
>
>
> --
> --------------------------
> Sent from my FrankenBerry Wireless Handheld
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Don Brown <mr...@apache.org>.
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
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Adam Winer <aw...@gmail.com>.
On 4/9/06, Jacob Hookom <ja...@hookom.net> 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 <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >>
> >
> >
>
>
> --
> --------------------------
> Sent from my FrankenBerry Wireless Handheld
>
>
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Jacob Hookom <ja...@hookom.net>.
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 <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Don Brown <mr...@twdata.org>.
Sorry, I meant to type Stripes, not Wicket.
Don
Michael Jouravlev wrote:
> On 4/9/06, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Michael Jouravlev <jm...@gmail.com>.
On 4/9/06, Don Brown <mr...@twdata.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Gabe <gj...@yahoo.com>.
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 <mr...@twdata.org>
To: Struts Developers List <de...@struts.apache.org>
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 <mr...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Don Brown <mr...@twdata.org>.
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 <mr...@apache.org> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Michael Jouravlev <jm...@gmail.com>.
On 4/9/06, Don Brown <mr...@apache.org> 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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Jacob Hookom <ja...@hookom.net>.
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 <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>
>
--
--------------------------
Sent from my FrankenBerry Wireless Handheld
Re: Fwd: Action/Shale/JSF Overlap? (Was --> RESTful JSF)
Posted by Don Brown <mr...@apache.org>.
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 <ja...@hookom.net> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org