Of course this is what Craig wanted the whole time. Lord! And, it is what the rest of the world has been trying to avoid. Now, it comes again in the back door. Don't any committers know where the front door is?
On 5/21/06, Don Brown <[EMAIL PROTECTED]> wrote:
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]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
