RE: [action2] Combining JSF and SAF2
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: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]
Re: [action2] Combining JSF and SAF2
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 [EMAIL PROTECTED] 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-actionindex/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] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown [EMAIL PROTECTED] 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-actionindex/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] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Re: [action2] Combining JSF and SAF2
Oh wonderful, more comments from the list idiot. K. On 5/21/06, Dakota Jack [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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-actionindex/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] -- 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]
Re: [action2] Combining JSF and SAF2
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 [EMAIL PROTECTED] wrote: I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown [EMAIL PROTECTED] 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-actionindex/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] -- 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]
Re: [action2] Combining JSF and SAF2
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 [EMAIL PROTECTED] 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-actionindex/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]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - 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]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - 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] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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-actionindex/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] __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - 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] - 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]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - 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] - 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] -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
This post shows who the limited person is. It is you, Ma'am. On 5/21/06, Kimani Darisha [EMAIL PROTECTED] wrote: Oh wonderful, more comments from the list idiot. K. On 5/21/06, Dakota Jack [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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-actionindex/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] -- 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] -- 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]
Re: [action2] Combining JSF and SAF2
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] wrote: I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown [EMAIL PROTECTED] 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-actionindex/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] -- 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] -- 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]
Re: [action2] Combining JSF and SAF2
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=31659messageID=61356#61356 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
From: Dakota Jack [EMAIL PROTECTED] 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. Sheese, sorry this got your panties in a bunch. On 5/21/06, Kimani Darisha 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 wrote: I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown 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: 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] -- 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] -- 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]
Re: [action2] Combining JSF and SAF2
Of course you aren't, Gary, because my panties are not in a bunch. You are the one with his panties in a bunch because you are here for JSF and JSF alone anyway and you don't like me having pointed out that your contributions did not merit your status. You can side with Kamini if you like, but she is the one of the real trolls on this list. You just don't like what I say. If you have trouble with me because of what I say, then you have black and white thinking. If you like what people like Kamini say, then you are just beyond interest. On 5/21/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Dakota Jack [EMAIL PROTECTED] 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. Sheese, sorry this got your panties in a bunch. On 5/21/06, Kimani Darisha 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 wrote: I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown 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: 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] -- 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] -- 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] -- 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]
Re: [action2] Combining JSF and SAF2
From: Dakota Jack [EMAIL PROTECTED] Of course you aren't, Gary, because my panties are not in a bunch. You are the one with his panties in a bunch because you are here for JSF and JSF alone anyway and you don't like me having pointed out that your contributions did not merit your status. You can side with Kamini if you like, but she is the one of the real trolls on this list. You just don't like what I say. If you have trouble with me because of what I say, then you have black and white thinking. If you like what people like Kamini say, then you are just beyond interest. No, I don't care about that. I think that Clay is a pretty fun trick and might make folks think about alternatives to using the JSP JSF technology. It's not the best or only solution either. Facelets is another very interesting solution. In many aspects superior to Clay. I had a chance to talk with Howard Lewis Ship last week about new features in Tapestry. I also talked with Jacob Hookem about Facelets. I was honored that they would take the time to share their ideas with me. But, really, there might be something to be learned with Don's proposal. It's really easy to get caught up in the merits of technology but the question is, will people be able to better automate there business? At JavaOne 2006, Sun announces VB that will run under the java VM. Now, that's not my cup-of-tea but I bet that it will be a big hit in the business world. So, is finding ways to use Struts action and Struts Shale really that big of a deal? I also had a chance to attend Scott Ambler's session on Agile Modeling last week. He had a funny comment about how he had seen a lot of reinvention of the wheel in regards to web services. He said something like, it was a half bake retooling of CICS. I've often thought of SOA that way too and kind of thought that at some level the whole JavaSpaces and BEPL was similar to JCL. There was also a session on AJAX/SOA and Web 2.0 that they discussed the re branding of these technologies. I guess that my point is that we will always be looking for better ways to solve our problems in a smaller window of time using spins on the same technology and at the same time, trying to leverage existing investments. This is in a market that doesn't always value the people that have the knowledge of their business or the people that automate the business using technologies. So, what have you done for me lately? Well, not only the Struts and other apache communities but Commercial vendors contribute their time and ideas and are trying to make their products better by using open source as the vehicle. I attended a session on project tango. Oh my, first class interoperability between java and .Net. This is Human sacrifice, dogs and cats, living together... mass hysteria!. Yet, it's hard for you to understand why two java web frameworks would want to achieve interoperability. Which pill would you take, the red or the blue?. I don't know if we each have a destiny, or if we're all just floatin' around accidental-like on a breeze. I think maybe it's both. But, That's all I have to say about that. Gary On 5/21/06, Gary VanMatre wrote: From: Dakota Jack 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. Sheese, sorry this got your panties in a bunch. On 5/21/06, Kimani Darisha 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 wrote: I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown 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
RE: [action2] Combining JSF and SAF2
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-actionindex/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]
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... 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
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 [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... 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [action2] Combining JSF and SAF2
Sounds like Ted. Let me say that anyone that says web services is a half-baked CICS is really not worth listening to. That is ridiculous. I am really amazed at the nutty things said on this list. If you think that web services is coincident with SOA that is equal madness. Do you guys think these things through or just mix the newest words around the best you can figure it out? SOA is an architecture. You really have to know what you are doing to use CICS right in SOA, which is done with all the major players in this arena, even with web services. So far as I can see, you don't understand much you are talking about. I'm not at all against JSF or other solutions of any kind. What I hate is people who in order to market themselves lie and manipulate people who trust them. That is the only thing I have against JSF, the attempt to market it buy taking space where it does not belong. Anyone who brings JSF to Struts cannot be working on too much voltage. On 5/21/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: Dakota Jack [EMAIL PROTECTED] Of course you aren't, Gary, because my panties are not in a bunch. You are the one with his panties in a bunch because you are here for JSF and JSF alone anyway and you don't like me having pointed out that your contributions did not merit your status. You can side with Kamini if you like, but she is the one of the real trolls on this list. You just don't like what I say. If you have trouble with me because of what I say, then you have black and white thinking. If you like what people like Kamini say, then you are just beyond interest. No, I don't care about that. I think that Clay is a pretty fun trick and might make folks think about alternatives to using the JSP JSF technology. It's not the best or only solution either. Facelets is another very interesting solution. In many aspects superior to Clay. I had a chance to talk with Howard Lewis Ship last week about new features in Tapestry. I also talked with Jacob Hookem about Facelets. I was honored that they would take the time to share their ideas with me. But, really, there might be something to be learned with Don's proposal. It's really easy to get caught up in the merits of technology but the question is, will people be able to better automate there business? At JavaOne 2006, Sun announces VB that will run under the java VM. Now, that's not my cup-of-tea but I bet that it will be a big hit in the business world. So, is finding ways to use Struts action and Struts Shale really that big of a deal? I also had a chance to attend Scott Ambler's session on Agile Modeling last week. He had a funny comment about how he had seen a lot of reinvention of the wheel in regards to web services. He said something like, it was a half bake retooling of CICS. I've often thought of SOA that way too and kind of thought that at some level the whole JavaSpaces and BEPL was similar to JCL. There was also a session on AJAX/SOA and Web 2.0 that they discussed the re branding of these technologies. I guess that my point is that we will always be looking for better ways to solve our problems in a smaller window of time using spins on the same technology and at the same time, trying to leverage existing investments. This is in a market that doesn't always value the people that have the knowledge of their business or the people that automate the business using technologies. So, what have you done for me lately? Well, not only the Struts and other apache communities but Commercial vendors contribute their time and ideas and are trying to make their products better by using open source as the vehicle. I attended a session on project tango. Oh my, first class interoperability between java and .Net. This is Human sacrifice, dogs and cats, living together... mass hysteria!. Yet, it's hard for you to understand why two java web frameworks would want to achieve interoperability. Which pill would you take, the red or the blue?. I don't know if we each have a destiny, or if we're all just floatin' around accidental-like on a breeze. I think maybe it's both. But, That's all I have to say about that. Gary On 5/21/06, Gary VanMatre wrote: From: Dakota Jack 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. Sheese, sorry this got your panties in a bunch. On 5/21/06, Kimani Darisha 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 wrote: I have seen no very popular need. This is like Bush-Speak. Baloney parading as truth. On 5/21/06, Don Brown 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
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 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-actionindex/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~
Re: [action2] Combining JSF and SAF2
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 [EMAIL PROTECTED] wrote: 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... 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~
