http://www.jsfcentral.com/products/components/
~~~Kito
D. Mann ([EMAIL PROTECTED])Author, JavaServer Faces in Actionhttp://www.virtua.com - JSF/J2EE consulting,
training, and mentoringhttp://www.JSFCentral.com - JavaServer
Faces FAQ, news, and info
From: Dakota Jack
[mailto:[EMAIL PROTECTED] Sent: Monday, May 22, 2006 1:08
AMTo: Struts Developers List; [EMAIL PROTECTED]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 < [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
isgrowing nicely).I wonder how well Shale will run in this
context...~~~~~~~
Kito D. Mann ([EMAIL PROTECTED])Author, JavaServer
Faces in Actionhttp://www.virtua.com
- JSF/J2EE consulting, training, and mentoringhttp://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:>>>
class="org.apache.struts.action2.showcase.jsf.EmployeeAction
">>
>
>
>
index>
>> 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]
