Below is my interpretation of the interface based on earlier discussion and such. Note that I suggest we change the name from "PageController" to "ViewController", although I don't feel very strongly about it. It's just one method (plus some javadoc to flesh out the idea.)
package org.apache.struts.action;
public interface ViewController {
/**
* <p>Perform any view-level preparations after an [EMAIL PROTECTED] Action} has executed
* and before the display is rendered. Return a [EMAIL PROTECTED] ForwardConfig}
* instance describing where and how control should be forwarded, or
* <code>null</code> if the response has already been completed.</p>
*
* <p>In the simplest case, where an implementation only modifies the
* request context, the return value may be the same as the <code>ForwardConfig</code>
* provided as an argument. However, note that implementations should not
* directly modify the given ForwardConfig if it is not the appropriate
* return value; they must instead return a new instance
* (or an implementation-level cached instance).</p>
*
* @param forward The ForwardConfig in whose context this controller is
* being invoked.
* @param request The HTTP request we are processing
* @param response The HTTP response we are creating
* @return a ForwardConfig which will be used for final view dispatch,
* or null if the response has already been completed
* @exception Exception if the view preparation process throws
* an exception
*/
public ForwardConfig prepareView(
ForwardConfig forward,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;
I think it's important (as noted in the JavaDoc) to help people understand that they can't change a "frozen" ForwardConfig. (I kind of feel like this belongs more in something like o.a.s.view, but if it's going to be the only class there...)
At 10:31 -0400 9/15/03, Ted Husted wrote:
I'll post more on this later, but to avoid the "gotcha", I'm now thinking we should try this using a modified ActionMapping.findForward method. In that way, all the navigational control stays within the Action.
The part that seems like it might raise some discussion is about who manages the ViewControllers. It seems wasteful to instantiate one each time a view is dispatched. So then does the base ActionMapping cache ViewControllers? If that's the case, then what about Module-level "global forwards"? You could make a simple support class that wrapped up the instantiation and caching and have it available to ActionMapping and implementations of ModuleConfig -- and just to note, the fact that ModuleConfig is an interface leaves open the risk that existing implementations wouldn't implement the new, more complex contract of "findForwardConfig".
I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see the gotcha that makes hiding this behavior in ActionMapping better than making it the responsibility of the RequestProcessor, which seems like a clearer place to put a single cache of ViewController classes -- which seems to be how Tiles works.
If people want to weigh in on this, I'll distill the discussion into draft code once we think the path is clear.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "We want beef in dessert if we can get it there."
-- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]