Hmm...I agree with your premise that there are two types of JSF
integration use cases:
1. The JSf app that wants some action-driven pages
2. The Struts 2 app that wants to use JSF components
However, I don't see why both aren't serviced by the existing code
today. To meet use case #1, you could define a wildcard that basically
hands most requests off to JSF automatically then configure the
exceptions. For use case #2, the Showcase example demonstrates how it
is possible.
What specific functionality do you see missing?
Rod :)
Chris Waring wrote:
I've been working with the Struts2 JSF Integration and I wanted to run a few
ideas past the development community.
First, I would like to give a high level description of the functionality
that I see as being desirable as well as why I believe it to be so.
Second, I would like to give a description of some of the design ideas to
see if their are better alternatives available to meet the described
functionality.
THE MARKET PITCH:
I see Struts2 JSF integration as a good lure to get JSF developers
interested in checking out Struts2. With that said I think that the end
implementation should be able to support both an integrated lifecycle where
Struts2 takes over the duties of executing Actions, performing validation,
handling result navigation, and all the other things that Struts2 does well,
as well as a wrapped lifecycle where Struts2 supports pre and post
processing of the default JSF Lifecycle. In this second case JSF would
handle everything in it's standard way but integrated with in the Struts2
Lifecycle stack to support things like error handling, etc. that JSF seems
to lack.
Why support two different JSF lifecycle implementations?
My thought here is that if we can add value to a project that already has
invested development into JSF, while keeping the "barrier to entry" to
integrate with Struts2 to a minimum, we ought to be able to attract a number
of JSF projects that are already in progress to try us out. On the other
side, if you are evaluating frameworks for a new project, it might be
attractive to be able to use Struts2 but still be able to use JSF
components. In this situation it would be nice to be able to use a single
configuration file and not have to learn the faces-config.xml.
How would the integrated lifecycle work?
JSF 1.1 supports six phases but it does so by using only 2 Lifecycle events.
It has an execute() and a render(). I see Struts2 integrating right between
those two lifecycle methods. The Struts 2 lifecycle stack could be
something like:
FacesSetupInterceptor - Accepts parms for configuring JSF application,
lifecycle, etc.
FacesExecuteLifecyleInterceptor - Would create the JSF lifecycle and
perform and call the execute() portion of the JSF lifecycle.
(Normal Action call would occur)
FacesResult - Would use the Struts2 result uri to construct a new jsf
UIViewRoot. Calls the render portion of the JSF lifecycle.
How would the wrapped lifecycle work?
The wrapped lifecycle would rely on a properly configured faces-config.xml
and would not allow the normal action processing to occur. The lifecycle
stack could be as simple as a single jsf interceptor.
FacesFullLifecycleInterceptor - Creates the JSF lifecycle. Calls both
execute() and render() methods on the lifecycle. Returns null to prevent
further processing.
If people think that this would be beneficial, I am willing to do most of
the coding, testing and documentation for it.
I already have a good start on the code for the integrated lifecycle part,
thanks in part to Rod Browns efforts. Let me know if I should continue to
work on this.
Thank You,
--Chris Waring
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
