struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Lee" <crazy...@crazybob.org>
Subject Re: [action2] Combining JSF and SAF2
Date Sun, 21 May 2006 16:39:37 GMT
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 <mrdon@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


Mime
View raw message