Instead of creating a new class, we could just associate an Action class with the ActionForward. This is what people do now anyway. It seems to work, but wastes an ActionMapping and trip through the container.
So, we just add a "type" property to ActionForward, and a step to the RequestProcessor to handle it when available. If it's there, it gets called, and the RequestProcess forward to the path. If it's not there, the RP forwards to the path given by the original forward. Everything else remains the same.
I'm sure some people will misuse the feature, but some people will always misuse any feature. At least this way, we recognize what most people (including me) already do most of the time, put an Action in front of page. The advantage being that we don't have to waste an ActionMapping or a trip through the container just to forward to the page.
-Ted.
Joe Germuska wrote:
I've been thinking about this a bit; as I see it now, some implementation choices might be a little contentious, so I feel like the right approach is discuss first, code later.
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
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
"Get Ready, We're Moving Out!!" - <http://www.clark04.com>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
