On 7/11/05, Schaub, Stephen <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote: > > On the other hand, Stephen, why do you want to have one class per > > page? > > Because I don't want to have to have two classes per page. :)
you got me :) I wanted to ask, why would you want to have one *set of classes* for one page, but seems that is not what you want. You just want to combine Action and ActionForm which was my idea too. > Let me clarify that I'm not arguing for one class per page: > in fact, I don't mind having one class backing multiple pages. > Just as Struts allows for one ActionForm that backs multiple JSP's, > my approach allows for one SimpleActionForm that backs multiple > JSP's. I've been working this afternoon on just such a use case. > > What I'm wanting is an explanation of why I should keep the > ActionForm class _separate_ from the Action class. It seems to me > that this unnecessarily complicates the application design. I wanted to combine these two classes as well, but I am not so sure now. Action class is stateless and can serve several requests, whereas action form either is instantiated for every request, or is stateful within a session, and has only one instance per session. Also, Struts is based on idea of subclassing, thus if you already subclassing something like ValidateForm, you cannot subclass another form, which you would want to because it has needed event handlers. So, these differences allow to mix and match and to combine. For example, I have a component which provides CRUD functionality (is it OK that I use my library as an example?). In this case the interface with browser is pretty much stable, it has create(), edit(), view(), delete() and of course render() methods. So, each particular project can reuse not only the protocol, but the implementation too. It is quite standard, it processes button events, it handles error messages, and it returns different mappings for different state of the ActionForm. This Action is totally reusable. On the other hand, every application has its own data which I don't know how to handle. So I have an interface for an action form, which I use from my standard action class. This interface defines what should be done with data for each input event, but it does not define how it should be done. You implement this interface in your ActionForm and go crazy with your data. I don't care what you do, just return back an error message and set status accordingly. What if it were a solid dispatching ActionForm as you suggest? In this case you would not be able to subclass other class like ValidateForm, because multiple inheritance does not exist in Java. At the same time your base ActionForm most likely would not have any functionality, because it depends on actual data. For UI interface, if you decide to add one event, it probably does not really matter, to use a separate action class for that, or to override all form classes... No firm opinion on that. Anyway, I agree that combining Action and ActionForm can be beneficial, but I would not want to *replace* current Struts Action/ActionForm combination with a solid ActionForm. > > Page is not what you load by browser. You load a resource, which > > can potentially generate many different pages. > > I'm not sure I follow. Can you explain further with an example? > I do want to understand. Never mind, I wrote this because I thought that you wanted to "go to login.htm", "then go to homepage.htm" instead of "go to login location, which will display whatever page is proper for current application state". Because if you have stateful objects on the server, and you load a resource, you do not know what exact content you receive. It all depends on server state. But seems that this concept is clear to you, sorry for hitting into the open door ;) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
