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]
