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.Believe it or not, I am not using LookupDispatchAction at all in my current application (see the @author tags for a laugh). And even when/if I have a need for it, I'll have to come up with some tricks (see previous discussions on this topic) to be able to use my custom BaseAction as the parent class yet still use LDA or LDA-like functionality under it. All actions in our system must extend from BaseAction - it just gives us a finer level of control.
For the lookup table CRUD pages, all our lookup tables have good naming conventions, so I wrote some reflection based stuff that takes care of all tables in one action, and did a simplified LDA-like piece under the covers. There is one JSP page for the list of all tables, one for the list of items where you choose to add/edit/delete, and one for editing/creating item detail - these service all tables.
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?No, not at all correct. I have a Delete<whatever>Action and a List<whatever>Action... all specific to their function. While a generic DeleteAction could be done, it would require very good and strict naming conventions and would prevent compile-time checking. While a global reflection-based scheme would be sort of slick, its not how I do it (except as mentioned above for the simple CRUD tables).
unless you had to have custom business logic for the deletion of an entity.Exactly. The example I gave was a simplified one, but fairly realistic. But there are actions in our system which require a little logic, but typically not much. Most actions are only a couple of lines of code - I use BeanUtils with custom registered Converters to make transferring VO's to/from form beans trivial and a one-line operation.
For instance, when I delete a user, I need to delete all other entities associated with that user.
Cascading deletes?! :)
Hmmm, sounds like I might want to stick with my LDA architecture. Thoughts?Seems reasonable - you have a scheme you like and works well for you. Thankfully Struts allows us all to have our own ways of doing things and they all work. But that is a negative also... too many ways to do things and not a lot of best practices. I've recently gotten two of the new Struts books: Sam's Struts Kick Start and Manning's Struts in Action (thanks to James, Kevin, and Ted and Craig et al for their hard work - I know what it takes now, and I respect those that endure authoring that much more now!). These books all have their own ways of doing things.
Now if I was to inherit or be called into a job with an existing large Struts app, I'd likely scream at the practices I see going on as it would differ dramatically from what I like :)
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
