~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito
D. Mann ([EMAIL PROTECTED])
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
Are there any figures on this market junk? Or is this more Bush-Speak, lies to get someone thinking your way?
From: Dakota Jack [mailto:[EMAIL PROTECTED]
Sent: Monday, May 22, 2006 1:08 AM
To: Struts Developers List; [EMAIL PROTECTED]
Subject: Re: [action2] Combining JSF and SAF2
On 5/21/06, Kito D. Mann < [EMAIL PROTECTED]> 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 ([EMAIL PROTECTED])
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:[EMAIL PROTECTED] ]
> 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: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
