Clearly, the application logic control code goes in the Action classes, or classes available to Action classes. And, the application data goes in the ActionForm.
What about code and data that exists solely to drive the presentation? For example, consider a field named event. This field holds various values to control the flow of the presentation. Should this field be part of the ActionForm? Or, because it isn't business data, should it be handled outside of the ActionForm, through the request/session objects? That one is sort of picky. But, what about a field like showDetails? When it is one value one UI experience happens, and when another value, another experience happens. Should this field be in the ActionForm, assuming control logic for the field is coded in the jsp? Or should it be in the request/session? Furthermore, what about the control logic to choose the UI experience above? Should that go in the JSP turning on portions of jsp markup? Or, should it go in the Action, calling different ActionForwards based on value? The second method (Action-ActionForwards) seem like the more MVC way to work, but it might end up it a bunch of jsps to maintain, or some nasty jsp includes (i.e. which jsp gets the <form>, which gets the </form>.) Combining JSP blocks and switching them on and off with control structures reduces the multiple jsp problem, but might not be the best design for some reason. Thoughts? thanks - gene __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
