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]
