Hi Scott, this is how I would implemented it. What we have is a standard CRUD stuff for Entity object. There are two ways to navigate to Entity. Either you simply navigate to it and it renders itself according to its state, or you navigate to it with a certain command, like "view" or "update" or "delete" or "create". The latter way is simpler and occurs more often and is easiter to understand and implement, so let's discuss that one.
Say, you have a table with a rows, each row represents an Entity. You may click the row to pull Entity out. Say, each row has links like "view", "update" or "delete". There is also one link or button called "create". To view, update or delete an entity, you call EntityAction with a corresponding command along with entity ID. To create an entity you call EntityAction without ID. See, EntityAction is a perfect candidate to be implemented with dispatch action, I suggest EventDispatchAction. If you call EntityAction with "view" command, the action loads existing entity and forwards to "view_entity.jsp". I prefer to use session-scoped formbeans so I set Entity state in the form to "view". If you prefer to use request-scoped beans, you can save Entity state in the hidden field in "view_entity.jsp". Same thing with "edit" command, the action loads existing entity, sets state to "edit" and forwards to "edit_entity.jsp". To create Entity, the action initializes formbean, sets state to "create" and forwards to "create_entity.jsp". In fact, all these JSP pages may be actually one page, you just need to update the title and maybe to show/hide ID field. After you filled in the form, you call EntityAction with "store" command. It validates the input and then tries to update/store data. If input is not valid, the action checks the state field and forward to a JSP that corresponds to that state. The page will be displayed along with the errors. If data is saved successfully, you forward to your success page, which is probably the item list. Same with deletion, after "delete" event is served, you forward to success page. So, the only problem here is what happens if a user navigates to EntityAction without command parameter? This is up to you. If you use dispatch action, you would correlate commands with action methods. If no command is passed to the action, the execute() will be called instead of a specific method handler. Because there is no active Entity, you can either show "No entity" message or forward to some error page. If you prefer to use redirection instead of forwarding, then you would have to either save state on the server (this is what I do), or to pass all state info in redirected request. A combination of these approaches is to pass Entity ID and maybe mode ID (like "updating" or "creating") in redirected request, and to store everything else in the session. As you may see, one dispatch action, one form bean and maybe even one JSP page is enough to serve all your commands. Michael. On 6/8/06, Scott Van Wart <[EMAIL PROTECTED]> wrote:
Michael Jouravlev wrote: > I suggest to look at your issue from another perspective. Do you > really need the functionality you are asking for? First, a small > clarification. There is no input page for an action, "input" attribute > is poorly named, it should be called "error" or "errorTarget", because > Struts forwards to that location if input data does not validate. Your > request is always sent to action/actionform. That might be it then... it might just be a matter of having to separate things out a little more. So let's say I had a page that edits an entity. I might call this edit_entity.jsp, with an EntityForm, and a SaveEntityAction. I found things got a little cumbersome in the .jsp, so I separated it out into a create_entity.jsp and edit_entity.jsp. These two forms submit to the same action. Obviously, they have a lot of code in common, but I thought of factoring that out into tags. Perhaps I should do the same thing to the action class (CreateEntityAction and UpdateEntityAction rather than all-encompassing SaveEntityAction; any code duplication can go into base classes or utility classes). The other side of this is that I also have a ShowEntityForm and ShowEntityAction. The action is mapped to /showEntity, and there are three forward mappings from there. Two are "success"-like forwards called "create" and "edit", which forward to create_entity.jsp and edit_entity.jsp. The 3rd one, the "failure" forward's destination would depend on who called /showEntity in the first place. The ShowEntityForm has validation, to ensure the given entityId is a number, and the "failure" forward gets hit when the entityId can't be found in the database table. While I can break the "failure" out into multiple forwards, I can't do the same with input. So the question is, then, do I break up my ShowEntityXxxxx classes into things like NewEntityAction->create_entity.jsp->CreateEntityAction and EditEntityAction->edit_entity.jsp->UpdateEntityAction? It's starting to sound like a lot more classes, but if I'm on the right track, and if that's how Struts is designed, then perhaps that's the point. Or I could be completely off my rocker. :) - Scott
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
