Getting back to classic MVC: The Model retains the state of the application. The View renders state and acquires input. The Controller accepts input from the View, updates the Model, and selects the next View. The selected View renders the updated Model, closing the loop.
For enterprise applications, including web apps, coupling the View to Model (via the Observer pattern) is problematic, and so we came up with MVC2. The View acquires input and passes it to the Controller (initiating a request). The Controller consults the Model, selects the next View, and passes back whatever output is needed. The View renders the output, completing the request. Something to note is that classic MVC is a loop, with balanced responsibilities. Enterprise MVC is layered, and places more responsibility on the Controller. In MVC, the Controller just has to select the next View. In MVC2, the Controller also has to know what output the selected View expects. Knowing what output the selected View expects is the issue recent threads have been pounding. If a Struts forward can obtain a "model" for its View, then we move closer to classic MVC. We don't want an actual server page running off and talking to business objects, but the ViewHelper can do it as the page's delegate. And, if the ViewHelper needs to populate an ActionForm, that's easy enough to do with a method on the standard base class. We just have to be very careful that we don't split selecting the next View between the Action and the ViewHelper. The Action handles navigation, *not* the ViewHelper. In the event of a real emergency, the ViewHelper would have to throw an exception and let the ExceptionHandler deal with it. One possible exception to the ViewHelper not selecting views is localization. I've often thought it would be handy if we could register multiple pages with a Struts forward and have it select one or the other based on Locale. Of couse, this would be not so much view selection, but subview selection. (Same view, different rendering.) Prior to 1.3.x, selecting a subview based on locale is problematic, since the component doesn't have access to the locale object. But, if we were to start passing in the ActionContext, that problem goes away. One other issue is whether a ViewHelper can render the response directly. My first inclination would be to let the ViewHelper render a direct response, and deprecate allowing the Action to do the same. Then the Action would be in the request-processing business, and the ViewHelper would be in the response-processing business. To sum up, * Add a ViewHelper base class with an Execute method. * A ViewHelper type is specified as an optional property to ForwardConfig. * The Execute method returns true if RequestProcess should transfer to a URI path, or false if the response is complete. * A ForwardConfig path can be optional if a ViewHelper is specified. * A ForwardConfig could specify multiple URI paths by Locale. * Deprecate returning null from an Action. (Eventually, it would become a fatal error.) Implied: * Actions might act as "covers" for an ActionForward, but all linking should still be to Actions. * Actions should be able to give local aliases to global ActionForwards (name="success" forward="$GlobalForward"). -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
