You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Jacob Hookom <ja...@hookom.net> on 2006/04/10 00:29:48 UTC
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 <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 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
>
>