I have a baseAction (of course).
The concrete actions, for example UserAction has {
onDelete(){}
onSave(){}
onDisplayList() {}
onInsert() {}
}
The baseAction dispatches execute event.
In some cases those events go to the super class, if they are simple. But at least I have palace to do custom processing for that one thing (as well as having a place for generic processing in base).
Above I think is implied in the Husted book.
I think having a standard DeleteAction is not as good.
.V
Eddie Bush wrote:
Naw - I think what he's saying is that, like you'd have a showUsers which would populate a userForm, then you'd have, say ... createUser, readUser, updateUser, deleteUser. Your deleteUser would then chain back to showUsers so the list could be viewed again. At least ... I think that's kind of what is being discussed :-) You're over-generalizing I believe, Matt ;-) You've got a nifty though, but I'd think it would be a big PITA to implement.
Matt Raible wrote:
I can't help chiming in as I'm in the midst of writing an example application using Struts for a Wrox book (Professional JSP 2.0). On my last Struts application, I used LookupDispatchAction's for all my actions. I basically organized it by entities, so that I had a UserAction, SearchAction, EventAction for the different types of activities. This seemed to work pretty well, and each class had their respective CRUD details.
What Erik seems to be suggesting is having a handful of generic actions - so you end up with DeleteAction, SaveAction, etc. that maybe use reflection to figure out the entity to delete, save, etc? Am I reading this correctly? Sounds like a neat idea, and would probably work, unless you had to have custom business logic for the deletion of an entity. For instance, when I delete a user, I need to delete all other entities associated with that user. Hmmm, sounds like I might want to stick with my LDA architecture. Thoughts?
Matt
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
