You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2006/05/21 09:55:01 UTC
[action2] Combining JSF and SAF2
After talking with several on this list about the possibility of
combining the best of JSF and Action 2 in a unified framework from a
user perspective, I have completed a first cut at JSF support in Action
2 with this loftly goal.
From a user perspective, you still have one configuration file,
struts-action.xml, which maps urls to actions and actions to results.
However, you can optionally include the JSF interceptor stack and use
the JSF result, allowing you to use JSF components in the view. You
still define alternative results the same way, still have an action
class per url, and can still use the normal GET-style navigation.
From a framework perspective, I split the lifecycle class into
indivudal Action 2 interceptors, one per phase. The final render phase
I turned into a Result. Upon initialization, I replace the navigation
handler with one that simply records outcomes as if they were result
codes from an Action. Also, the setup inserts a variable resolver that
exposes the action instance to the EL bindings. Therefore, the flow
goes: determine action/namespace -> run normal interceptors -> run JSF
phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
render phase. The purpose of the Action then becomes as a general setup
for the page, much like the Shale pre-render hook.
I chose this approach because I find the Action 2 controller stronger
(JSF was always meant as a view tech, as I understand it), so think it
better suited for navigation, state-less actions, and centralizing page
setup code. JSF is better for complex single pages or page groups where
different stateful components might be needing to submit the page
without affecting others.
To demonstrate this integration, I added a JSF tab to the showcase. As
a sneak peek, here is the action mapping for a JSF page that edits an
employee:
<action name="employee"
class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
<interceptor-ref name="basicStack"/>
<interceptor-ref name="jsfStack"/>
<result name="success" type="jsf" />
<result name="index" type="redirect-action">index</result>
</action>
Notice the default page is the JSF page, but other navigation is handled
by traditional Action 2 results. Incidently, this means only POSTs for
real form submits and bookmarkable GETS everywhere else.
I'm sure there is a lot of refinement to do, but I'm hoping this general
approach will solve the very popular need to combine the two frameworks
in a seamless way for the user. I'm particularly interested in feedback
from the JSF folks, as I'm pretty new to the framework.
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by netsql <ne...@roomity.com>.
Like I said before, use Shale to fork from, adding the JSP to it. (or if
shale adds JSP tags, no reason for SAF2).
.V
Jason Carreira wrote:
>
> I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile.
>
> Don, does this make SAF a full JSF implementation (minus the bundled components)?
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
[action2] Configuring interceptors (was Re: Combining JSF and SAF2)
Posted by Chris Nokleberg <ch...@sixlegs.com>.
On Sun, 21 May 2006 12:44:02 -0700, Don Brown wrote:
> You can inherit packages and their defined defaults. Therefore, in this
> case, you could define the default interceptor stack and result type for
> a root package then not have to specify it in any action configs of that
> package or child packages.
I've always disliked this part of WebWork (forgive me if things are
different now, my understanding is based on older versions of WebWork).
Managing the order of the interceptors is important, and it usually ends
up being much simpler and less fragile just to let every action use the
full stack of interceptors rather than explicitly picking and choosing
separate stacks for each action. This in turn can hurt performance by
having to chain through unnecessary interceptors, or hurt app design by
discouraging fine-grained interceptors.
In another web framework I've worked on, the configuration defines exactly
two stacks of interceptors--one for actions, and one for views. However,
the common interface for the interceptors includes this method:
boolean enable(Mapping mapping)
At startup, the framework asks asks each interceptor in the chain whether
it should be enabled for each mapping. For example, if the interceptor
relies on copying information from the context to the Action, it can
return "false" if it can see that the Action impl for a particular mapping
does not have any setters. Other interceptors might only enable
themselves if the mapping URL matches a particular pattern. The framework
then uses this information to construct *mapping-specific* chains. The
interceptors in these chains are in the same order as the full chain
defined by the config, but some (or most) interceptors will be removed for
any given mapping.
Furthermore, there is a way to store interceptor-specific data in the
Mapping object itself. This enables interceptors to pre-calculate data in
the enable method which will speed request handling. For example, the
interceptor which copies information to the Action setters could cache an
array of Methods, or even generate some bytecode.
Chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Cool! Thanks :)
Frank
Don Brown wrote:
> You can inherit packages and their defined defaults. Therefore, in this
> case, you could define the default interceptor stack and result type for
> a root package then not have to specify it in any action configs of that
> package or child packages.
>
> Don
>
> Frank W. Zammetti wrote:
>> A bit of a tangential question here... does Webwork support
>> inheritance of some sort with regard to Action mappings? Or perhaps
>> some sort of prototype? I think it's great that you can set things on
>> a per-mapping basis, that makes things very flexible and powerful...
>> but one can imagine where that leads to rather complex-looking config
>> files... and I'm not sold on annotations yet, I'm still in the config
>> file camp myself... still, configuring everything per mapping could
>> get messy. If there is a way to have basically a prototype mapping
>> that others can inherit from, that would eliminate that possibility,
>> more or less. Just curious, because I've only done one Webwork
>> project thus far, and it's relatively basic, so I didn't have a need
>> for this capability.
>>
>> Frank
>>
>> Don Brown wrote:
>>> Frank W. Zammetti wrote:
>>>> I've been historically pretty anti-JSF, so I hope this means
>>>> something in light of that history: this is *very* interesting and I
>>>> congratulate you on making it happen! I've had the same "I think it
>>>> can be done" thoughts about mixing the two, just never actually did
>>>> anything with the idea, so I'm happy that someone has, if for no
>>>> other reason than to prove it can be done. Kudos!
>>>>
>>>> The one concern I have initially is about performance... as you
>>>> describe, running through all the normal interceptors, and *then*
>>>> going through the JSF phases, sounds like an awful lot of code to
>>>> execute per request. I wonder about how well this will scale. Time
>>>> will tell of course, but that is my one concern.
>>> This is why I left the JSF stack with just JSF phase interceptors and
>>> not including the whole default stack. This lets you mix and match
>>> at the action level, so if the action wanted the full action 2 stack
>>> plus JSF, it can, or it can just use the JSF phase interceptors. The
>>> full stack, or at least the params interceptor, is useful so that a
>>> page can accept an "id" parameter, then look up the data to be
>>> available in the JSF page later. In Action 2, nothing is forced an
>>> you, making it very easy to override or set other defaults as needed.
>>>
>>> Don
>>>>
>>>> Good work in any case Don, I look forward to seeing this polished!
>>>>
>>>> Frank
>>>>
>>>> Don Brown wrote:
>>>>> Jason Carreira wrote:
>>>>>> Great work Don! This is very cool. I've been saying we could do
>>>>>> this for a long time, but it's good to know I wasn't just making
>>>>>> that up :-)
>>>>>>
>>>>> Heh, I know. After bragging about it after many beers at JavaOne,
>>>>> I figured it was time to put up or shut up :)
>>>>>
>>>>>> I think it's interesting to think of the JSF lifecycle as a
>>>>>> particular profile of our interceptor lifecycle. Similarly, the
>>>>>> Portlet support is a different profile. For simple pages, you can
>>>>>> choose a simple profile.
>>>>>>
>>>>> Exactly. SAF2 makes a great controller.
>>>>>> Don, does this make SAF a full JSF implementation (minus the
>>>>>> bundled components)?
>>>>>>
>>>>> No, this requires a JSF implementation. For the example in
>>>>> showcase, I used MyFaces. The integration code, however, doesn't
>>>>> require any particular JSF implementation. If we were a full
>>>>> implementation, there would be a ton more code; not something I
>>>>> think we'd be interested in maintaining :)
>>>>>
>>>>> Don
>>>>>> ---------------------------------------------------------------------
>>>>>> Posted via Jive Forums
>>>>>> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> 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
>>>
>>>
>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Don Brown <mr...@twdata.org>.
You can inherit packages and their defined defaults. Therefore, in this
case, you could define the default interceptor stack and result type for
a root package then not have to specify it in any action configs of that
package or child packages.
Don
Frank W. Zammetti wrote:
> A bit of a tangential question here... does Webwork support
> inheritance of some sort with regard to Action mappings? Or perhaps
> some sort of prototype? I think it's great that you can set things on
> a per-mapping basis, that makes things very flexible and powerful...
> but one can imagine where that leads to rather complex-looking config
> files... and I'm not sold on annotations yet, I'm still in the config
> file camp myself... still, configuring everything per mapping could
> get messy. If there is a way to have basically a prototype mapping
> that others can inherit from, that would eliminate that possibility,
> more or less. Just curious, because I've only done one Webwork
> project thus far, and it's relatively basic, so I didn't have a need
> for this capability.
>
> Frank
>
> Don Brown wrote:
>> Frank W. Zammetti wrote:
>>> I've been historically pretty anti-JSF, so I hope this means
>>> something in light of that history: this is *very* interesting and I
>>> congratulate you on making it happen! I've had the same "I think it
>>> can be done" thoughts about mixing the two, just never actually did
>>> anything with the idea, so I'm happy that someone has, if for no
>>> other reason than to prove it can be done. Kudos!
>>>
>>> The one concern I have initially is about performance... as you
>>> describe, running through all the normal interceptors, and *then*
>>> going through the JSF phases, sounds like an awful lot of code to
>>> execute per request. I wonder about how well this will scale. Time
>>> will tell of course, but that is my one concern.
>> This is why I left the JSF stack with just JSF phase interceptors and
>> not including the whole default stack. This lets you mix and match
>> at the action level, so if the action wanted the full action 2 stack
>> plus JSF, it can, or it can just use the JSF phase interceptors. The
>> full stack, or at least the params interceptor, is useful so that a
>> page can accept an "id" parameter, then look up the data to be
>> available in the JSF page later. In Action 2, nothing is forced an
>> you, making it very easy to override or set other defaults as needed.
>>
>> Don
>>>
>>> Good work in any case Don, I look forward to seeing this polished!
>>>
>>> Frank
>>>
>>> Don Brown wrote:
>>>> Jason Carreira wrote:
>>>>> Great work Don! This is very cool. I've been saying we could do
>>>>> this for a long time, but it's good to know I wasn't just making
>>>>> that up :-)
>>>>>
>>>> Heh, I know. After bragging about it after many beers at JavaOne,
>>>> I figured it was time to put up or shut up :)
>>>>
>>>>> I think it's interesting to think of the JSF lifecycle as a
>>>>> particular profile of our interceptor lifecycle. Similarly, the
>>>>> Portlet support is a different profile. For simple pages, you can
>>>>> choose a simple profile.
>>>>>
>>>> Exactly. SAF2 makes a great controller.
>>>>> Don, does this make SAF a full JSF implementation (minus the
>>>>> bundled components)?
>>>>>
>>>> No, this requires a JSF implementation. For the example in
>>>> showcase, I used MyFaces. The integration code, however, doesn't
>>>> require any particular JSF implementation. If we were a full
>>>> implementation, there would be a ton more code; not something I
>>>> think we'd be interested in maintaining :)
>>>>
>>>> Don
>>>>> ---------------------------------------------------------------------
>>>>> Posted via Jive Forums
>>>>> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>>
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
A bit of a tangential question here... does Webwork support inheritance
of some sort with regard to Action mappings? Or perhaps some sort of
prototype? I think it's great that you can set things on a per-mapping
basis, that makes things very flexible and powerful... but one can
imagine where that leads to rather complex-looking config files... and
I'm not sold on annotations yet, I'm still in the config file camp
myself... still, configuring everything per mapping could get messy. If
there is a way to have basically a prototype mapping that others can
inherit from, that would eliminate that possibility, more or less. Just
curious, because I've only done one Webwork project thus far, and it's
relatively basic, so I didn't have a need for this capability.
Frank
Don Brown wrote:
> Frank W. Zammetti wrote:
>> I've been historically pretty anti-JSF, so I hope this means something
>> in light of that history: this is *very* interesting and I
>> congratulate you on making it happen! I've had the same "I think it
>> can be done" thoughts about mixing the two, just never actually did
>> anything with the idea, so I'm happy that someone has, if for no other
>> reason than to prove it can be done. Kudos!
>>
>> The one concern I have initially is about performance... as you
>> describe, running through all the normal interceptors, and *then*
>> going through the JSF phases, sounds like an awful lot of code to
>> execute per request. I wonder about how well this will scale. Time
>> will tell of course, but that is my one concern.
> This is why I left the JSF stack with just JSF phase interceptors and
> not including the whole default stack. This lets you mix and match at
> the action level, so if the action wanted the full action 2 stack plus
> JSF, it can, or it can just use the JSF phase interceptors. The full
> stack, or at least the params interceptor, is useful so that a page can
> accept an "id" parameter, then look up the data to be available in the
> JSF page later. In Action 2, nothing is forced an you, making it very
> easy to override or set other defaults as needed.
>
> Don
>>
>> Good work in any case Don, I look forward to seeing this polished!
>>
>> Frank
>>
>> Don Brown wrote:
>>> Jason Carreira wrote:
>>>> Great work Don! This is very cool. I've been saying we could do this
>>>> for a long time, but it's good to know I wasn't just making that up :-)
>>>>
>>> Heh, I know. After bragging about it after many beers at JavaOne, I
>>> figured it was time to put up or shut up :)
>>>
>>>> I think it's interesting to think of the JSF lifecycle as a
>>>> particular profile of our interceptor lifecycle. Similarly, the
>>>> Portlet support is a different profile. For simple pages, you can
>>>> choose a simple profile.
>>>>
>>> Exactly. SAF2 makes a great controller.
>>>> Don, does this make SAF a full JSF implementation (minus the bundled
>>>> components)?
>>>>
>>> No, this requires a JSF implementation. For the example in showcase,
>>> I used MyFaces. The integration code, however, doesn't require any
>>> particular JSF implementation. If we were a full implementation,
>>> there would be a ton more code; not something I think we'd be
>>> interested in maintaining :)
>>>
>>> Don
>>>> ---------------------------------------------------------------------
>>>> Posted via Jive Forums
>>>> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Don Brown <mr...@twdata.org>.
Frank W. Zammetti wrote:
> I've been historically pretty anti-JSF, so I hope this means something
> in light of that history: this is *very* interesting and I
> congratulate you on making it happen! I've had the same "I think it
> can be done" thoughts about mixing the two, just never actually did
> anything with the idea, so I'm happy that someone has, if for no other
> reason than to prove it can be done. Kudos!
>
> The one concern I have initially is about performance... as you
> describe, running through all the normal interceptors, and *then*
> going through the JSF phases, sounds like an awful lot of code to
> execute per request. I wonder about how well this will scale. Time
> will tell of course, but that is my one concern.
This is why I left the JSF stack with just JSF phase interceptors and
not including the whole default stack. This lets you mix and match at
the action level, so if the action wanted the full action 2 stack plus
JSF, it can, or it can just use the JSF phase interceptors. The full
stack, or at least the params interceptor, is useful so that a page can
accept an "id" parameter, then look up the data to be available in the
JSF page later. In Action 2, nothing is forced an you, making it very
easy to override or set other defaults as needed.
Don
>
> Good work in any case Don, I look forward to seeing this polished!
>
> Frank
>
> Don Brown wrote:
>> Jason Carreira wrote:
>>> Great work Don! This is very cool. I've been saying we could do this
>>> for a long time, but it's good to know I wasn't just making that up :-)
>>>
>> Heh, I know. After bragging about it after many beers at JavaOne, I
>> figured it was time to put up or shut up :)
>>
>>> I think it's interesting to think of the JSF lifecycle as a
>>> particular profile of our interceptor lifecycle. Similarly, the
>>> Portlet support is a different profile. For simple pages, you can
>>> choose a simple profile.
>>>
>> Exactly. SAF2 makes a great controller.
>>> Don, does this make SAF a full JSF implementation (minus the bundled
>>> components)?
>>>
>> No, this requires a JSF implementation. For the example in showcase,
>> I used MyFaces. The integration code, however, doesn't require any
>> particular JSF implementation. If we were a full implementation,
>> there would be a ton more code; not something I think we'd be
>> interested in maintaining :)
>>
>> Don
>>> ---------------------------------------------------------------------
>>> Posted via Jive Forums
>>> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: [action2] Combining JSF and SAF2
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I've been historically pretty anti-JSF, so I hope this means something
in light of that history: this is *very* interesting and I congratulate
you on making it happen! I've had the same "I think it can be done"
thoughts about mixing the two, just never actually did anything with the
idea, so I'm happy that someone has, if for no other reason than to
prove it can be done. Kudos!
The one concern I have initially is about performance... as you
describe, running through all the normal interceptors, and *then* going
through the JSF phases, sounds like an awful lot of code to execute per
request. I wonder about how well this will scale. Time will tell of
course, but that is my one concern.
Good work in any case Don, I look forward to seeing this polished!
Frank
Don Brown wrote:
> Jason Carreira wrote:
>> Great work Don! This is very cool. I've been saying we could do this
>> for a long time, but it's good to know I wasn't just making that up :-)
>>
> Heh, I know. After bragging about it after many beers at JavaOne, I
> figured it was time to put up or shut up :)
>
>> I think it's interesting to think of the JSF lifecycle as a particular
>> profile of our interceptor lifecycle. Similarly, the Portlet support
>> is a different profile. For simple pages, you can choose a simple
>> profile.
>>
> Exactly. SAF2 makes a great controller.
>> Don, does this make SAF a full JSF implementation (minus the bundled
>> components)?
>>
> No, this requires a JSF implementation. For the example in showcase, I
> used MyFaces. The integration code, however, doesn't require any
> particular JSF implementation. If we were a full implementation, there
> would be a ton more code; not something I think we'd be interested in
> maintaining :)
>
> Don
>> ---------------------------------------------------------------------
>> Posted via Jive Forums
>> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>
>
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
Java Web Parts -
http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Don Brown <mr...@twdata.org>.
Jason Carreira wrote:
> Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-)
>
Heh, I know. After bragging about it after many beers at JavaOne, I
figured it was time to put up or shut up :)
> I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile.
>
Exactly. SAF2 makes a great controller.
> Don, does this make SAF a full JSF implementation (minus the bundled components)?
>
No, this requires a JSF implementation. For the example in showcase, I
used MyFaces. The integration code, however, doesn't require any
particular JSF implementation. If we were a full implementation, there
would be a ton more code; not something I think we'd be interested in
maintaining :)
Don
> ---------------------------------------------------------------------
> Posted via Jive Forums
> http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
>
>
> ---------------------------------------------------------------------
> 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: [action2] Combining JSF and SAF2
Posted by Jason Carreira <fo...@opensymphony.com>.
> Don, this is *very* interesting. Nice work. I've been
> wondering for a
> while if we could reuse off-the-shelf JSF components.
> It looks like
> you may have figured out how!
>
> It also proves that you can think of the JSF
> lifecycle as a more
> complex, higher level of abstraction of our
> interceptor lifecycle.
> From my experience, it's a *lot* easier to reason
> about and maintain
> the simpler interceptor lifecycle.
>
> Bob
>
Great work Don! This is very cool. I've been saying we could do this for a long time, but it's good to know I wasn't just making that up :-)
I think it's interesting to think of the JSF lifecycle as a particular profile of our interceptor lifecycle. Similarly, the Portlet support is a different profile. For simple pages, you can choose a simple profile.
Don, does this make SAF a full JSF implementation (minus the bundled components)?
---------------------------------------------------------------------
Posted via Jive Forums
http://forums.opensymphony.com/thread.jspa?threadID=31659&messageID=61356#61356
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Paul Benedict <pa...@yahoo.com>.
I am not opposed to having JSF and Action2 work together.
If they can play together, and you can find a business case to
parts of each in a project, I think that's a big win. As long
as they can still be used separately, then I am +1.
--- Bob Lee <cr...@crazybob.org> wrote:
> Don, this is *very* interesting. Nice work. I've been wondering for a
> while if we could reuse off-the-shelf JSF components. It looks like
> you may have figured out how!
>
> It also proves that you can think of the JSF lifecycle as a more
> complex, higher level of abstraction of our interceptor lifecycle.
> From my experience, it's a *lot* easier to reason about and maintain
> the simpler interceptor lifecycle.
>
> Bob
>
> On 5/21/06, Don Brown <mr...@twdata.org> wrote:
> > After talking with several on this list about the possibility of
> > combining the best of JSF and Action 2 in a unified framework from a
> > user perspective, I have completed a first cut at JSF support in Action
> > 2 with this loftly goal.
> >
> > From a user perspective, you still have one configuration file,
> > struts-action.xml, which maps urls to actions and actions to results.
> > However, you can optionally include the JSF interceptor stack and use
> > the JSF result, allowing you to use JSF components in the view. You
> > still define alternative results the same way, still have an action
> > class per url, and can still use the normal GET-style navigation.
> >
> > From a framework perspective, I split the lifecycle class into
> > indivudal Action 2 interceptors, one per phase. The final render phase
> > I turned into a Result. Upon initialization, I replace the navigation
> > handler with one that simply records outcomes as if they were result
> > codes from an Action. Also, the setup inserts a variable resolver that
> > exposes the action instance to the EL bindings. Therefore, the flow
> > goes: determine action/namespace -> run normal interceptors -> run JSF
> > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> > render phase. The purpose of the Action then becomes as a general setup
> > for the page, much like the Shale pre-render hook.
> >
> > I chose this approach because I find the Action 2 controller stronger
> > (JSF was always meant as a view tech, as I understand it), so think it
> > better suited for navigation, state-less actions, and centralizing page
> > setup code. JSF is better for complex single pages or page groups where
> > different stateful components might be needing to submit the page
> > without affecting others.
> >
> > To demonstrate this integration, I added a JSF tab to the showcase. As
> > a sneak peek, here is the action mapping for a JSF page that edits an
> > employee:
> >
> > <action name="employee"
> > class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> > <interceptor-ref name="basicStack"/>
> > <interceptor-ref name="jsfStack"/>
> > <result name="success" type="jsf" />
> > <result name="index" type="redirect-action">index</result>
> > </action>
> >
> > Notice the default page is the JSF page, but other navigation is handled
> > by traditional Action 2 results. Incidently, this means only POSTs for
> > real form submits and bookmarkable GETS everywhere else.
> >
> > I'm sure there is a lot of refinement to do, but I'm hoping this general
> > approach will solve the very popular need to combine the two frameworks
> > in a seamless way for the user. I'm particularly interested in feedback
> > from the JSF folks, as I'm pretty new to the framework.
> >
> > Don
> >
> > ---------------------------------------------------------------------
> > 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
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Bob Lee <cr...@crazybob.org>.
Don, this is *very* interesting. Nice work. I've been wondering for a
while if we could reuse off-the-shelf JSF components. It looks like
you may have figured out how!
It also proves that you can think of the JSF lifecycle as a more
complex, higher level of abstraction of our interceptor lifecycle.
>From my experience, it's a *lot* easier to reason about and maintain
the simpler interceptor lifecycle.
Bob
On 5/21/06, Don Brown <mr...@twdata.org> wrote:
> After talking with several on this list about the possibility of
> combining the best of JSF and Action 2 in a unified framework from a
> user perspective, I have completed a first cut at JSF support in Action
> 2 with this loftly goal.
>
> From a user perspective, you still have one configuration file,
> struts-action.xml, which maps urls to actions and actions to results.
> However, you can optionally include the JSF interceptor stack and use
> the JSF result, allowing you to use JSF components in the view. You
> still define alternative results the same way, still have an action
> class per url, and can still use the normal GET-style navigation.
>
> From a framework perspective, I split the lifecycle class into
> indivudal Action 2 interceptors, one per phase. The final render phase
> I turned into a Result. Upon initialization, I replace the navigation
> handler with one that simply records outcomes as if they were result
> codes from an Action. Also, the setup inserts a variable resolver that
> exposes the action instance to the EL bindings. Therefore, the flow
> goes: determine action/namespace -> run normal interceptors -> run JSF
> phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> render phase. The purpose of the Action then becomes as a general setup
> for the page, much like the Shale pre-render hook.
>
> I chose this approach because I find the Action 2 controller stronger
> (JSF was always meant as a view tech, as I understand it), so think it
> better suited for navigation, state-less actions, and centralizing page
> setup code. JSF is better for complex single pages or page groups where
> different stateful components might be needing to submit the page
> without affecting others.
>
> To demonstrate this integration, I added a JSF tab to the showcase. As
> a sneak peek, here is the action mapping for a JSF page that edits an
> employee:
>
> <action name="employee"
> class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> <interceptor-ref name="basicStack"/>
> <interceptor-ref name="jsfStack"/>
> <result name="success" type="jsf" />
> <result name="index" type="redirect-action">index</result>
> </action>
>
> Notice the default page is the JSF page, but other navigation is handled
> by traditional Action 2 results. Incidently, this means only POSTs for
> real form submits and bookmarkable GETS everywhere else.
>
> I'm sure there is a lot of refinement to do, but I'm hoping this general
> approach will solve the very popular need to combine the two frameworks
> in a seamless way for the user. I'm particularly interested in feedback
> from the JSF folks, as I'm pretty new to the framework.
>
> Don
>
> ---------------------------------------------------------------------
> 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: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
This post shows who the limited person is. It is you, Ma'am.
On 5/21/06, Kimani Darisha <kd...@gmail.com> wrote:
> Oh wonderful, more comments from the list idiot.
>
> K.
>
> On 5/21/06, Dakota Jack <da...@gmail.com> wrote:
> > Who wants these frameworks combined? This is what has been killing Struts.
> > This is anything but a lofty goal. It is architectural suicide. There is
> > Shale, which could not really do this. Why is that not enough or in fact
> > way too much? This is ridiculous. I hope people on this list see this
> > effort for what it is.
> >
> > On 5/21/06, Don Brown <mr...@twdata.org> wrote:
> > >
> > > After talking with several on this list about the possibility of
> > > combining the best of JSF and Action 2 in a unified framework from a
> > > user perspective, I have completed a first cut at JSF support in Action
> > > 2 with this loftly goal.
> > >
> > > From a user perspective, you still have one configuration file,
> > > struts-action.xml, which maps urls to actions and actions to results.
> > > However, you can optionally include the JSF interceptor stack and use
> > > the JSF result, allowing you to use JSF components in the view. You
> > > still define alternative results the same way, still have an action
> > > class per url, and can still use the normal GET-style navigation.
> > >
> > > From a framework perspective, I split the lifecycle class into
> > > indivudal Action 2 interceptors, one per phase. The final render phase
> > > I turned into a Result. Upon initialization, I replace the navigation
> > > handler with one that simply records outcomes as if they were result
> > > codes from an Action. Also, the setup inserts a variable resolver that
> > > exposes the action instance to the EL bindings. Therefore, the flow
> > > goes: determine action/namespace -> run normal interceptors -> run JSF
> > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> > > render phase. The purpose of the Action then becomes as a general setup
> > > for the page, much like the Shale pre-render hook.
> > >
> > > I chose this approach because I find the Action 2 controller stronger
> > > (JSF was always meant as a view tech, as I understand it), so think it
> > > better suited for navigation, state-less actions, and centralizing page
> > > setup code. JSF is better for complex single pages or page groups where
> > > different stateful components might be needing to submit the page
> > > without affecting others.
> > >
> > > To demonstrate this integration, I added a JSF tab to the showcase. As
> > > a sneak peek, here is the action mapping for a JSF page that edits an
> > > employee:
> > >
> > > <action name="employee"
> > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> > > <interceptor-ref name="basicStack"/>
> > > <interceptor-ref name="jsfStack"/>
> > > <result name="success" type="jsf" />
> > > <result name="index" type="redirect-action">index</result>
> > > </action>
> > >
> > > Notice the default page is the JSF page, but other navigation is handled
> > > by traditional Action 2 results. Incidently, this means only POSTs for
> > > real form submits and bookmarkable GETS everywhere else.
> > >
> > > I'm sure there is a lot of refinement to do, but I'm hoping this general
> > > approach will solve the very popular need to combine the two frameworks
> > > in a seamless way for the user. I'm particularly interested in feedback
> > > from the JSF folks, as I'm pretty new to the framework.
> > >
> > > Don
> > >
> > > ---------------------------------------------------------------------
> > > 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~
> >
> >
>
> ---------------------------------------------------------------------
> 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~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Kimani Darisha <kd...@gmail.com>.
Oh wonderful, more comments from the list idiot.
K.
On 5/21/06, Dakota Jack <da...@gmail.com> wrote:
> Who wants these frameworks combined? This is what has been killing Struts.
> This is anything but a lofty goal. It is architectural suicide. There is
> Shale, which could not really do this. Why is that not enough or in fact
> way too much? This is ridiculous. I hope people on this list see this
> effort for what it is.
>
> On 5/21/06, Don Brown <mr...@twdata.org> wrote:
> >
> > After talking with several on this list about the possibility of
> > combining the best of JSF and Action 2 in a unified framework from a
> > user perspective, I have completed a first cut at JSF support in Action
> > 2 with this loftly goal.
> >
> > From a user perspective, you still have one configuration file,
> > struts-action.xml, which maps urls to actions and actions to results.
> > However, you can optionally include the JSF interceptor stack and use
> > the JSF result, allowing you to use JSF components in the view. You
> > still define alternative results the same way, still have an action
> > class per url, and can still use the normal GET-style navigation.
> >
> > From a framework perspective, I split the lifecycle class into
> > indivudal Action 2 interceptors, one per phase. The final render phase
> > I turned into a Result. Upon initialization, I replace the navigation
> > handler with one that simply records outcomes as if they were result
> > codes from an Action. Also, the setup inserts a variable resolver that
> > exposes the action instance to the EL bindings. Therefore, the flow
> > goes: determine action/namespace -> run normal interceptors -> run JSF
> > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> > render phase. The purpose of the Action then becomes as a general setup
> > for the page, much like the Shale pre-render hook.
> >
> > I chose this approach because I find the Action 2 controller stronger
> > (JSF was always meant as a view tech, as I understand it), so think it
> > better suited for navigation, state-less actions, and centralizing page
> > setup code. JSF is better for complex single pages or page groups where
> > different stateful components might be needing to submit the page
> > without affecting others.
> >
> > To demonstrate this integration, I added a JSF tab to the showcase. As
> > a sneak peek, here is the action mapping for a JSF page that edits an
> > employee:
> >
> > <action name="employee"
> > class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> > <interceptor-ref name="basicStack"/>
> > <interceptor-ref name="jsfStack"/>
> > <result name="success" type="jsf" />
> > <result name="index" type="redirect-action">index</result>
> > </action>
> >
> > Notice the default page is the JSF page, but other navigation is handled
> > by traditional Action 2 results. Incidently, this means only POSTs for
> > real form submits and bookmarkable GETS everywhere else.
> >
> > I'm sure there is a lot of refinement to do, but I'm hoping this general
> > approach will solve the very popular need to combine the two frameworks
> > in a seamless way for the user. I'm particularly interested in feedback
> > from the JSF folks, as I'm pretty new to the framework.
> >
> > Don
> >
> > ---------------------------------------------------------------------
> > 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~
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
Who wants these frameworks combined? This is what has been killing Struts.
This is anything but a lofty goal. It is architectural suicide. There is
Shale, which could not really do this. Why is that not enough or in fact
way too much? This is ridiculous. I hope people on this list see this
effort for what it is.
On 5/21/06, Don Brown <mr...@twdata.org> wrote:
>
> After talking with several on this list about the possibility of
> combining the best of JSF and Action 2 in a unified framework from a
> user perspective, I have completed a first cut at JSF support in Action
> 2 with this loftly goal.
>
> From a user perspective, you still have one configuration file,
> struts-action.xml, which maps urls to actions and actions to results.
> However, you can optionally include the JSF interceptor stack and use
> the JSF result, allowing you to use JSF components in the view. You
> still define alternative results the same way, still have an action
> class per url, and can still use the normal GET-style navigation.
>
> From a framework perspective, I split the lifecycle class into
> indivudal Action 2 interceptors, one per phase. The final render phase
> I turned into a Result. Upon initialization, I replace the navigation
> handler with one that simply records outcomes as if they were result
> codes from an Action. Also, the setup inserts a variable resolver that
> exposes the action instance to the EL bindings. Therefore, the flow
> goes: determine action/namespace -> run normal interceptors -> run JSF
> phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> render phase. The purpose of the Action then becomes as a general setup
> for the page, much like the Shale pre-render hook.
>
> I chose this approach because I find the Action 2 controller stronger
> (JSF was always meant as a view tech, as I understand it), so think it
> better suited for navigation, state-less actions, and centralizing page
> setup code. JSF is better for complex single pages or page groups where
> different stateful components might be needing to submit the page
> without affecting others.
>
> To demonstrate this integration, I added a JSF tab to the showcase. As
> a sneak peek, here is the action mapping for a JSF page that edits an
> employee:
>
> <action name="employee"
> class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> <interceptor-ref name="basicStack"/>
> <interceptor-ref name="jsfStack"/>
> <result name="success" type="jsf" />
> <result name="index" type="redirect-action">index</result>
> </action>
>
> Notice the default page is the JSF page, but other navigation is handled
> by traditional Action 2 results. Incidently, this means only POSTs for
> real form submits and bookmarkable GETS everywhere else.
>
> I'm sure there is a lot of refinement to do, but I'm hoping this general
> approach will solve the very popular need to combine the two frameworks
> in a seamless way for the user. I'm particularly interested in feedback
> from the JSF folks, as I'm pretty new to the framework.
>
> Don
>
> ---------------------------------------------------------------------
> 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: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
You are right, for once. I only speak for myself. Those who are
unwilling to listen to others are condemned by their own choice to a
life of ignorance.
On 5/21/06, Kimani Darisha <kd...@gmail.com> wrote:
> To anyone following these thread, please ignore this fool. He does
> not speak for anyone, and is only here to confuse people.
>
> K.
>
> On 5/21/06, Dakota Jack <da...@gmail.com> wrote:
> > I have seen no "very popular need". This is like Bush-Speak. Baloney
> > parading as truth.
> >
> > On 5/21/06, Don Brown <mr...@twdata.org> wrote:
> > >
> > > After talking with several on this list about the possibility of
> > > combining the best of JSF and Action 2 in a unified framework from a
> > > user perspective, I have completed a first cut at JSF support in Action
> > > 2 with this loftly goal.
> > >
> > > From a user perspective, you still have one configuration file,
> > > struts-action.xml, which maps urls to actions and actions to results.
> > > However, you can optionally include the JSF interceptor stack and use
> > > the JSF result, allowing you to use JSF components in the view. You
> > > still define alternative results the same way, still have an action
> > > class per url, and can still use the normal GET-style navigation.
> > >
> > > From a framework perspective, I split the lifecycle class into
> > > indivudal Action 2 interceptors, one per phase. The final render phase
> > > I turned into a Result. Upon initialization, I replace the navigation
> > > handler with one that simply records outcomes as if they were result
> > > codes from an Action. Also, the setup inserts a variable resolver that
> > > exposes the action instance to the EL bindings. Therefore, the flow
> > > goes: determine action/namespace -> run normal interceptors -> run JSF
> > > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> > > render phase. The purpose of the Action then becomes as a general setup
> > > for the page, much like the Shale pre-render hook.
> > >
> > > I chose this approach because I find the Action 2 controller stronger
> > > (JSF was always meant as a view tech, as I understand it), so think it
> > > better suited for navigation, state-less actions, and centralizing page
> > > setup code. JSF is better for complex single pages or page groups where
> > > different stateful components might be needing to submit the page
> > > without affecting others.
> > >
> > > To demonstrate this integration, I added a JSF tab to the showcase. As
> > > a sneak peek, here is the action mapping for a JSF page that edits an
> > > employee:
> > >
> > > <action name="employee"
> > > class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> > > <interceptor-ref name="basicStack"/>
> > > <interceptor-ref name="jsfStack"/>
> > > <result name="success" type="jsf" />
> > > <result name="index" type="redirect-action">index</result>
> > > </action>
> > >
> > > Notice the default page is the JSF page, but other navigation is handled
> > > by traditional Action 2 results. Incidently, this means only POSTs for
> > > real form submits and bookmarkable GETS everywhere else.
> > >
> > > I'm sure there is a lot of refinement to do, but I'm hoping this general
> > > approach will solve the very popular need to combine the two frameworks
> > > in a seamless way for the user. I'm particularly interested in feedback
> > > from the JSF folks, as I'm pretty new to the framework.
> > >
> > > Don
> > >
> > > ---------------------------------------------------------------------
> > > 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~
> >
> >
>
> ---------------------------------------------------------------------
> 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~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Kimani Darisha <kd...@gmail.com>.
To anyone following these thread, please ignore this fool. He does
not speak for anyone, and is only here to confuse people.
K.
On 5/21/06, Dakota Jack <da...@gmail.com> wrote:
> I have seen no "very popular need". This is like Bush-Speak. Baloney
> parading as truth.
>
> On 5/21/06, Don Brown <mr...@twdata.org> wrote:
> >
> > After talking with several on this list about the possibility of
> > combining the best of JSF and Action 2 in a unified framework from a
> > user perspective, I have completed a first cut at JSF support in Action
> > 2 with this loftly goal.
> >
> > From a user perspective, you still have one configuration file,
> > struts-action.xml, which maps urls to actions and actions to results.
> > However, you can optionally include the JSF interceptor stack and use
> > the JSF result, allowing you to use JSF components in the view. You
> > still define alternative results the same way, still have an action
> > class per url, and can still use the normal GET-style navigation.
> >
> > From a framework perspective, I split the lifecycle class into
> > indivudal Action 2 interceptors, one per phase. The final render phase
> > I turned into a Result. Upon initialization, I replace the navigation
> > handler with one that simply records outcomes as if they were result
> > codes from an Action. Also, the setup inserts a variable resolver that
> > exposes the action instance to the EL bindings. Therefore, the flow
> > goes: determine action/namespace -> run normal interceptors -> run JSF
> > phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> > render phase. The purpose of the Action then becomes as a general setup
> > for the page, much like the Shale pre-render hook.
> >
> > I chose this approach because I find the Action 2 controller stronger
> > (JSF was always meant as a view tech, as I understand it), so think it
> > better suited for navigation, state-less actions, and centralizing page
> > setup code. JSF is better for complex single pages or page groups where
> > different stateful components might be needing to submit the page
> > without affecting others.
> >
> > To demonstrate this integration, I added a JSF tab to the showcase. As
> > a sneak peek, here is the action mapping for a JSF page that edits an
> > employee:
> >
> > <action name="employee"
> > class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> > <interceptor-ref name="basicStack"/>
> > <interceptor-ref name="jsfStack"/>
> > <result name="success" type="jsf" />
> > <result name="index" type="redirect-action">index</result>
> > </action>
> >
> > Notice the default page is the JSF page, but other navigation is handled
> > by traditional Action 2 results. Incidently, this means only POSTs for
> > real form submits and bookmarkable GETS everywhere else.
> >
> > I'm sure there is a lot of refinement to do, but I'm hoping this general
> > approach will solve the very popular need to combine the two frameworks
> > in a seamless way for the user. I'm particularly interested in feedback
> > from the JSF folks, as I'm pretty new to the framework.
> >
> > Don
> >
> > ---------------------------------------------------------------------
> > 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~
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
I have seen no "very popular need". This is like Bush-Speak. Baloney
parading as truth.
On 5/21/06, Don Brown <mr...@twdata.org> wrote:
>
> After talking with several on this list about the possibility of
> combining the best of JSF and Action 2 in a unified framework from a
> user perspective, I have completed a first cut at JSF support in Action
> 2 with this loftly goal.
>
> From a user perspective, you still have one configuration file,
> struts-action.xml, which maps urls to actions and actions to results.
> However, you can optionally include the JSF interceptor stack and use
> the JSF result, allowing you to use JSF components in the view. You
> still define alternative results the same way, still have an action
> class per url, and can still use the normal GET-style navigation.
>
> From a framework perspective, I split the lifecycle class into
> indivudal Action 2 interceptors, one per phase. The final render phase
> I turned into a Result. Upon initialization, I replace the navigation
> handler with one that simply records outcomes as if they were result
> codes from an Action. Also, the setup inserts a variable resolver that
> exposes the action instance to the EL bindings. Therefore, the flow
> goes: determine action/namespace -> run normal interceptors -> run JSF
> phases -> invoke JSF action (optional) -> invoke SAF2 action -> invoke
> render phase. The purpose of the Action then becomes as a general setup
> for the page, much like the Shale pre-render hook.
>
> I chose this approach because I find the Action 2 controller stronger
> (JSF was always meant as a view tech, as I understand it), so think it
> better suited for navigation, state-less actions, and centralizing page
> setup code. JSF is better for complex single pages or page groups where
> different stateful components might be needing to submit the page
> without affecting others.
>
> To demonstrate this integration, I added a JSF tab to the showcase. As
> a sneak peek, here is the action mapping for a JSF page that edits an
> employee:
>
> <action name="employee"
> class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> <interceptor-ref name="basicStack"/>
> <interceptor-ref name="jsfStack"/>
> <result name="success" type="jsf" />
> <result name="index" type="redirect-action">index</result>
> </action>
>
> Notice the default page is the JSF page, but other navigation is handled
> by traditional Action 2 results. Incidently, this means only POSTs for
> real form submits and bookmarkable GETS everywhere else.
>
> I'm sure there is a lot of refinement to do, but I'm hoping this general
> approach will solve the very popular need to combine the two frameworks
> in a seamless way for the user. I'm particularly interested in feedback
> from the JSF folks, as I'm pretty new to the framework.
>
> Don
>
> ---------------------------------------------------------------------
> 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: [action2] Combining JSF and SAF2
Posted by "Kito D. Mann" <km...@virtua.com>.
http://www.jsfcentral.com/products/components/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann (kmann@virtua.com)
Author, JavaServer Faces in Action
http://www.virtua.com <http://www.virtua.com/> - JSF/J2EE consulting,
training, and mentoring
http://www.JSFCentral.com <http://www.jsfcentral.com/> - JavaServer Faces
FAQ, news, and info
_____
From: Dakota Jack [mailto:dakota.jack@gmail.com]
Sent: Monday, May 22, 2006 1:08 AM
To: Struts Developers List; kmann@virtua.com
Subject: Re: [action2] Combining JSF and SAF2
Are there any figures on this market junk? Or is this more Bush-Speak, lies
to get someone thinking your way?
On 5/21/06, Kito D. Mann < kmann@virtua.com <ma...@virtua.com> >
wrote:
Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This
will allow SAF2 developers to work with JSF components (and the market is
growing nicely).
I wonder how well Shale will run in this context...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann (kmann@virtua.com)
Author, JavaServer Faces in Action
http://www.virtua.com - JSF/J2EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> -----Original Message-----
> From: Don Brown [mailto:mrdon@twdata.org <ma...@twdata.org> ]
> Sent: Sunday, May 21, 2006 3:55 AM
> To: Struts Developers List
> Subject: [action2] Combining JSF and SAF2
>
> After talking with several on this list about the possibility
> of combining the best of JSF and Action 2 in a unified
> framework from a user perspective, I have completed a first
> cut at JSF support in Action
> 2 with this loftly goal.
>
> From a user perspective, you still have one configuration
> file, struts-action.xml, which maps urls to actions and
> actions to results.
> However, you can optionally include the JSF interceptor stack
> and use the JSF result, allowing you to use JSF components in
> the view. You still define alternative results the same way,
> still have an action class per url, and can still use the
> normal GET-style navigation.
>
> From a framework perspective, I split the lifecycle class
> into indivudal Action 2 interceptors, one per phase. The
> final render phase I turned into a Result. Upon
> initialization, I replace the navigation handler with one
> that simply records outcomes as if they were result codes
> from an Action. Also, the setup inserts a variable resolver
> that exposes the action instance to the EL bindings.
> Therefore, the flow
> goes: determine action/namespace -> run normal interceptors
> -> run JSF phases -> invoke JSF action (optional) -> invoke
> SAF2 action -> invoke render phase. The purpose of the
> Action then becomes as a general setup for the page, much
> like the Shale pre-render hook.
>
> I chose this approach because I find the Action 2 controller
> stronger (JSF was always meant as a view tech, as I
> understand it), so think it better suited for navigation,
> state-less actions, and centralizing page setup code. JSF is
> better for complex single pages or page groups where
> different stateful components might be needing to submit the
> page without affecting others.
>
> To demonstrate this integration, I added a JSF tab to the
> showcase. As a sneak peek, here is the action mapping for a
> JSF page that edits an
> employee:
>
> <action name="employee"
> class="org.apache.struts.action2.showcase.jsf.EmployeeAction ">
> <interceptor-ref name="basicStack"/>
> <interceptor-ref name="jsfStack"/>
> <result name="success" type="jsf" />
> <result name="index" type="redirect-action">index</result>
> </action>
>
> Notice the default page is the JSF page, but other navigation
> is handled by traditional Action 2 results. Incidently, this
> means only POSTs for real form submits and bookmarkable GETS
> everywhere else.
>
> I'm sure there is a lot of refinement to do, but I'm hoping
> this general approach will solve the very popular need to
> combine the two frameworks in a seamless way for the user.
> I'm particularly interested in feedback from the JSF folks,
> as I'm pretty new to the framework.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
<ma...@struts.apache.org>
>
---------------------------------------------------------------------
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: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
Are there any figures on this market junk? Or is this more Bush-Speak, lies
to get someone thinking your way?
On 5/21/06, Kito D. Mann <km...@virtua.com> wrote:
>
> Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This
> will allow SAF2 developers to work with JSF components (and the market is
> growing nicely).
>
> I wonder how well Shale will run in this context...
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann (kmann@virtua.com)
> Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/J2EE consulting, training, and mentoring
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>
> > -----Original Message-----
> > From: Don Brown [mailto:mrdon@twdata.org]
> > Sent: Sunday, May 21, 2006 3:55 AM
> > To: Struts Developers List
> > Subject: [action2] Combining JSF and SAF2
> >
> > After talking with several on this list about the possibility
> > of combining the best of JSF and Action 2 in a unified
> > framework from a user perspective, I have completed a first
> > cut at JSF support in Action
> > 2 with this loftly goal.
> >
> > From a user perspective, you still have one configuration
> > file, struts-action.xml, which maps urls to actions and
> > actions to results.
> > However, you can optionally include the JSF interceptor stack
> > and use the JSF result, allowing you to use JSF components in
> > the view. You still define alternative results the same way,
> > still have an action class per url, and can still use the
> > normal GET-style navigation.
> >
> > From a framework perspective, I split the lifecycle class
> > into indivudal Action 2 interceptors, one per phase. The
> > final render phase I turned into a Result. Upon
> > initialization, I replace the navigation handler with one
> > that simply records outcomes as if they were result codes
> > from an Action. Also, the setup inserts a variable resolver
> > that exposes the action instance to the EL bindings.
> > Therefore, the flow
> > goes: determine action/namespace -> run normal interceptors
> > -> run JSF phases -> invoke JSF action (optional) -> invoke
> > SAF2 action -> invoke render phase. The purpose of the
> > Action then becomes as a general setup for the page, much
> > like the Shale pre-render hook.
> >
> > I chose this approach because I find the Action 2 controller
> > stronger (JSF was always meant as a view tech, as I
> > understand it), so think it better suited for navigation,
> > state-less actions, and centralizing page setup code. JSF is
> > better for complex single pages or page groups where
> > different stateful components might be needing to submit the
> > page without affecting others.
> >
> > To demonstrate this integration, I added a JSF tab to the
> > showcase. As a sneak peek, here is the action mapping for a
> > JSF page that edits an
> > employee:
> >
> > <action name="employee"
> > class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> > <interceptor-ref name="basicStack"/>
> > <interceptor-ref name="jsfStack"/>
> > <result name="success" type="jsf" />
> > <result name="index" type="redirect-action">index</result>
> > </action>
> >
> > Notice the default page is the JSF page, but other navigation
> > is handled by traditional Action 2 results. Incidently, this
> > means only POSTs for real form submits and bookmarkable GETS
> > everywhere else.
> >
> > I'm sure there is a lot of refinement to do, but I'm hoping
> > this general approach will solve the very popular need to
> > combine the two frameworks in a seamless way for the user.
> > I'm particularly interested in feedback from the JSF folks,
> > as I'm pretty new to the framework.
> >
> > Don
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
Since Kito is committed and has been to JSF Central, why pretend that he
needs to know about this. These are like those paid 1 hour commercials we
have to put up with on Sunday mornings that attempt to distort the truth.
Give us a break.
On 5/21/06, Craig McClanahan <cr...@apache.org> wrote:
>
> On 5/21/06, Kito D. Mann <km...@virtua.com> wrote:
> >
> > Congrats, Don! I'm very encouraged, and I'm anxious to check it out.
> This
> > will allow SAF2 developers to work with JSF components (and the market
> is
> > growing nicely).
> >
> > I wonder how well Shale will run in this context...
>
>
> Don and I had a chance to chat about this idea last week at JavaOne (glad
> to
> see the phase listener strategy worked out so well :-). You'll want to
> look
> at SAF2+JSF for cases where you've got a primarily action controller
> driven
> application architecture, but where you want to use some really cool JSF
> components here and there on your pages -- without *having* to convert the
> entire page to use components. You'll be able to do that, without
> throwing
> away all the rest of your architecture (but you won't be leveraging
> anything
> in JSF other than the components).
>
> If you're building an app around the JSF controller (perhaps because you
> like the JSF approach to navigation, or its lifecycle), on the other hand,
> you'd be better off starting with JSF+Shale. Just to make things a bit
> more
> interesting, several of the Struts committers got together and talked
> about
> how we can share common stuff between the two frameworks ... and some
> ideas
> that are already on the Shale roadmap[1][2] involve support for XWork
> interceptors in addition to (and probably ultimately preferred to) using
> Commons Chain to decorate the overall request lifecycle. This will likely
> end up being fairly similar to what Don did in terms of being able to
> customize each phase individually. I'll have more detailed comments when
> I've had a chance to dig in a little deeper.
>
> Craig
>
> [1] http://issues.apache.org/struts/browse/SHALE-108
> [2] http://issues.apache.org/struts/browse/SHALE-136
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Posted by Dakota Jack <da...@gmail.com>.
Of course this is what Craig wanted the whole time. Lord! And, it is what
the rest of the world has been trying to avoid. Now, it comes again in the
back door. Don't any committers know where the front door is?
On 5/21/06, Don Brown <mr...@twdata.org> wrote:
>
> In the Action 2 approach, you should be able to use any feature of
> Shale, or any other JSF extension, that doesn't involve a custom
> NavigationHandler, since that is overridden to defer to Action 2-style
> navigation, or a custom Lifecycle. By leaving JSF alone otherwise, you
> should be able to use fancy Ajax components or any other more intrusive
> extension that relies heavily on PhaseListeners or custom ViewHandlers.
>
> For me, Action 2 really makes JSF more palatable by remove two parts of
> JSF I found unnecessarily complex and tedious - navigation and required
> managed beans. You can still use navigation JSF components, but instead
> of all that navigation rule XML, you use Action 2's Results, which are
> simpler and more extensible. You can also still have managed beans, but
> since the Action is treated as one from an EL perspective, they are no
> longer required. Therefore, your JSF-enabled app doesn't need
> faces-config.xml at all.
>
> The downside is the Action 2-style navigation might not be as toolable
> and you lose some advantage of the tool support overall. However, from
> this old Struts user's perspective, I think this makes JSF much more
> attractive and easier to assimilate. Isn't that what you wanted, Craig,
> the whole time? ;)
>
> Don
>
> Craig McClanahan wrote:
> > On 5/21/06, Kito D. Mann <km...@virtua.com> wrote:
> >>
> >> Congrats, Don! I'm very encouraged, and I'm anxious to check it out.
> >> This
> >> will allow SAF2 developers to work with JSF components (and the
> >> market is
> >> growing nicely).
> >>
> >> I wonder how well Shale will run in this context...
> >
> >
> > Don and I had a chance to chat about this idea last week at JavaOne
> > (glad to
> > see the phase listener strategy worked out so well :-). You'll want
> > to look
> > at SAF2+JSF for cases where you've got a primarily action controller
> > driven
> > application architecture, but where you want to use some really cool JSF
> > components here and there on your pages -- without *having* to convert
> > the
> > entire page to use components. You'll be able to do that, without
> > throwing
> > away all the rest of your architecture (but you won't be leveraging
> > anything
> > in JSF other than the components).
> >
> > If you're building an app around the JSF controller (perhaps because you
> > like the JSF approach to navigation, or its lifecycle), on the other
> > hand,
> > you'd be better off starting with JSF+Shale. Just to make things a
> > bit more
> > interesting, several of the Struts committers got together and talked
> > about
> > how we can share common stuff between the two frameworks ... and some
> > ideas
> > that are already on the Shale roadmap[1][2] involve support for XWork
> > interceptors in addition to (and probably ultimately preferred to) using
> > Commons Chain to decorate the overall request lifecycle. This will
> > likely
> > end up being fairly similar to what Don did in terms of being able to
> > customize each phase individually. I'll have more detailed comments
> when
> > I've had a chance to dig in a little deeper.
> >
> > Craig
> >
> > [1] http://issues.apache.org/struts/browse/SHALE-108
> > [2] http://issues.apache.org/struts/browse/SHALE-136
> >
>
>
> ---------------------------------------------------------------------
> 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: [action2] Combining JSF and SAF2
Posted by Don Brown <mr...@twdata.org>.
In the Action 2 approach, you should be able to use any feature of
Shale, or any other JSF extension, that doesn't involve a custom
NavigationHandler, since that is overridden to defer to Action 2-style
navigation, or a custom Lifecycle. By leaving JSF alone otherwise, you
should be able to use fancy Ajax components or any other more intrusive
extension that relies heavily on PhaseListeners or custom ViewHandlers.
For me, Action 2 really makes JSF more palatable by remove two parts of
JSF I found unnecessarily complex and tedious - navigation and required
managed beans. You can still use navigation JSF components, but instead
of all that navigation rule XML, you use Action 2's Results, which are
simpler and more extensible. You can also still have managed beans, but
since the Action is treated as one from an EL perspective, they are no
longer required. Therefore, your JSF-enabled app doesn't need
faces-config.xml at all.
The downside is the Action 2-style navigation might not be as toolable
and you lose some advantage of the tool support overall. However, from
this old Struts user's perspective, I think this makes JSF much more
attractive and easier to assimilate. Isn't that what you wanted, Craig,
the whole time? ;)
Don
Craig McClanahan wrote:
> On 5/21/06, Kito D. Mann <km...@virtua.com> wrote:
>>
>> Congrats, Don! I'm very encouraged, and I'm anxious to check it out.
>> This
>> will allow SAF2 developers to work with JSF components (and the
>> market is
>> growing nicely).
>>
>> I wonder how well Shale will run in this context...
>
>
> Don and I had a chance to chat about this idea last week at JavaOne
> (glad to
> see the phase listener strategy worked out so well :-). You'll want
> to look
> at SAF2+JSF for cases where you've got a primarily action controller
> driven
> application architecture, but where you want to use some really cool JSF
> components here and there on your pages -- without *having* to convert
> the
> entire page to use components. You'll be able to do that, without
> throwing
> away all the rest of your architecture (but you won't be leveraging
> anything
> in JSF other than the components).
>
> If you're building an app around the JSF controller (perhaps because you
> like the JSF approach to navigation, or its lifecycle), on the other
> hand,
> you'd be better off starting with JSF+Shale. Just to make things a
> bit more
> interesting, several of the Struts committers got together and talked
> about
> how we can share common stuff between the two frameworks ... and some
> ideas
> that are already on the Shale roadmap[1][2] involve support for XWork
> interceptors in addition to (and probably ultimately preferred to) using
> Commons Chain to decorate the overall request lifecycle. This will
> likely
> end up being fairly similar to what Don did in terms of being able to
> customize each phase individually. I'll have more detailed comments when
> I've had a chance to dig in a little deeper.
>
> Craig
>
> [1] http://issues.apache.org/struts/browse/SHALE-108
> [2] http://issues.apache.org/struts/browse/SHALE-136
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [action2] Combining JSF and SAF2
Posted by Craig McClanahan <cr...@apache.org>.
On 5/21/06, Kito D. Mann <km...@virtua.com> wrote:
>
> Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This
> will allow SAF2 developers to work with JSF components (and the market is
> growing nicely).
>
> I wonder how well Shale will run in this context...
Don and I had a chance to chat about this idea last week at JavaOne (glad to
see the phase listener strategy worked out so well :-). You'll want to look
at SAF2+JSF for cases where you've got a primarily action controller driven
application architecture, but where you want to use some really cool JSF
components here and there on your pages -- without *having* to convert the
entire page to use components. You'll be able to do that, without throwing
away all the rest of your architecture (but you won't be leveraging anything
in JSF other than the components).
If you're building an app around the JSF controller (perhaps because you
like the JSF approach to navigation, or its lifecycle), on the other hand,
you'd be better off starting with JSF+Shale. Just to make things a bit more
interesting, several of the Struts committers got together and talked about
how we can share common stuff between the two frameworks ... and some ideas
that are already on the Shale roadmap[1][2] involve support for XWork
interceptors in addition to (and probably ultimately preferred to) using
Commons Chain to decorate the overall request lifecycle. This will likely
end up being fairly similar to what Don did in terms of being able to
customize each phase individually. I'll have more detailed comments when
I've had a chance to dig in a little deeper.
Craig
[1] http://issues.apache.org/struts/browse/SHALE-108
[2] http://issues.apache.org/struts/browse/SHALE-136
RE: [action2] Combining JSF and SAF2
Posted by "Kito D. Mann" <km...@virtua.com>.
Congrats, Don! I'm very encouraged, and I'm anxious to check it out. This
will allow SAF2 developers to work with JSF components (and the market is
growing nicely).
I wonder how well Shale will run in this context...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann (kmann@virtua.com)
Author, JavaServer Faces in Action
http://www.virtua.com - JSF/J2EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
> -----Original Message-----
> From: Don Brown [mailto:mrdon@twdata.org]
> Sent: Sunday, May 21, 2006 3:55 AM
> To: Struts Developers List
> Subject: [action2] Combining JSF and SAF2
>
> After talking with several on this list about the possibility
> of combining the best of JSF and Action 2 in a unified
> framework from a user perspective, I have completed a first
> cut at JSF support in Action
> 2 with this loftly goal.
>
> From a user perspective, you still have one configuration
> file, struts-action.xml, which maps urls to actions and
> actions to results.
> However, you can optionally include the JSF interceptor stack
> and use the JSF result, allowing you to use JSF components in
> the view. You still define alternative results the same way,
> still have an action class per url, and can still use the
> normal GET-style navigation.
>
> From a framework perspective, I split the lifecycle class
> into indivudal Action 2 interceptors, one per phase. The
> final render phase I turned into a Result. Upon
> initialization, I replace the navigation handler with one
> that simply records outcomes as if they were result codes
> from an Action. Also, the setup inserts a variable resolver
> that exposes the action instance to the EL bindings.
> Therefore, the flow
> goes: determine action/namespace -> run normal interceptors
> -> run JSF phases -> invoke JSF action (optional) -> invoke
> SAF2 action -> invoke render phase. The purpose of the
> Action then becomes as a general setup for the page, much
> like the Shale pre-render hook.
>
> I chose this approach because I find the Action 2 controller
> stronger (JSF was always meant as a view tech, as I
> understand it), so think it better suited for navigation,
> state-less actions, and centralizing page setup code. JSF is
> better for complex single pages or page groups where
> different stateful components might be needing to submit the
> page without affecting others.
>
> To demonstrate this integration, I added a JSF tab to the
> showcase. As a sneak peek, here is the action mapping for a
> JSF page that edits an
> employee:
>
> <action name="employee"
> class="org.apache.struts.action2.showcase.jsf.EmployeeAction">
> <interceptor-ref name="basicStack"/>
> <interceptor-ref name="jsfStack"/>
> <result name="success" type="jsf" />
> <result name="index" type="redirect-action">index</result>
> </action>
>
> Notice the default page is the JSF page, but other navigation
> is handled by traditional Action 2 results. Incidently, this
> means only POSTs for real form submits and bookmarkable GETS
> everywhere else.
>
> I'm sure there is a lot of refinement to do, but I'm hoping
> this general approach will solve the very popular need to
> combine the two frameworks in a seamless way for the user.
> I'm particularly interested in feedback from the JSF folks,
> as I'm pretty new to the framework.
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
>