Chris Waring wrote:
I wanted to just bullet point some things so that we can discuss them
seperately.

1) One lifecycle vs. two?  -  Does seperate lifecycles help reduce the
possibility of config errors that lead to an action method being called
twice?  Is there a better way to address this problem than creating seperate
lifecycles?
I'm not sure I see two lifecycles.  Could you give an exmple?
2) Should we be implementing each JSF Phase as it's own Struts Interceptor
or should we be using the JSF Lifecycle methods instead?  See JSF 1.1 Spec -
Section 11.1.
Actually, we are, or at least as much as we can. The JSF lifecycle methods, found in the Lifecycle class are private and therefore not able to be called directly. Only execute() and render() are exposed, which is too high of level to allow for proper integration. Therefore, I copied the contents of the phase methods (MyFaces HEAD) into new Interceptors. I'd love to use the Lifecycle class directly, if were possible.
3) Should we add the capability to configure the JSF application, phase
listeners, etc. from within the Struts config? How far do we go with this? I'm not sure that we would want to allow navigation, validation, and the
like to be configured using the Struts config?
I'd say no for now, but if we move to a more extensible XSD-based XML format later on, it might be interesting to combine them.

4) Should support be added to allow a uri to be used as part of the Struts
result?  - I believe this can be done by adding code to the FacesResult to
create a new UIViewRoot from the specified uri.
I'm not 100% following, but the core issue here is that the view id needs to be determined at the start of the process. In a normal Struts flow, the Result is executed after the Action, but in the JSF case, the Interceptors need to be aware of the Result in order to determine the view id. Could that be more configurable? Certainly.

Don
I think that is all I have for now.  :)

Thanks,
--Chris


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to