I would have a problem in the sense that you are limiting what your users can designate as use cases. Or can you add on top of this (i.e. override default behaviour?). For example I may want to update the table as a list (I know that there are many issues, but let's say this is valid). Meaning that for each row in the table and related tables I show the users editable fields which they can edit and submit back as a batch. If this is a utility that can be overriden then it would be useful. I have a feeling that things will get too complicated to maintain. What happens when there are related tables and not just one. This seems to imply a structure to the tables as defined by struts. Anyways, those are my thoughts. I am currently working on a project that started out being very complicated, but is now being simplified so that each project from each group behaves independantly of the others. There is too many problems. sandeep
-----Original Message----- From: Faus, Lee [mailto:[EMAIL PROTECTED] Sent: Monday, April 12, 2004 10:32 AM To: [EMAIL PROTECTED] Subject: Dispatch Action Questions I have an application that I am trying to architect using Struts. One of the questions we have is the advantage/disadvantage to each of the following approaches. 1. For each table in the database, we plan on having one form bean, and 4 action classes that will extend an ActionBase class. The four actions that will be used are CreateSomething, ReadSomething, UpdateSomething, DeleteSomething. This will give a good infrastructure for our application as it grows and it will allow us to build out a "pattern" for the entire application to let people know how they should build out their actions. On the downside, this is going to create a huge struts-config file as there are about 40 tables in the application. Imagine what would happen on an application that has 1,000 tables. 2. Look at the overall application and make decisions to have one form bean per use case, and one action per use case that will allow us to use the Dispatch Action to pass in a parameter for create, read, update, delete and have methods in the Action class to perform the above action. This is not as straight forward because a developer can interpret the use case differently and allow for some ambiguity as to the building of the form beans and actions and can make maintenance a nightmare. This would shrink our overall struts-config file to a point that it would be more manageable but at the sake of readability and manageability. I understand I could create multiple "struts-config" files for each use case and this is another solution we are investigating. What I need is best practice so we can standardize on a common architecture for all applications moving forward as well. I have seen examples of each on this forum and in the different struts books, so I am confused as the best approach moving forward. Any help would be greatly appreciated. N. Lee Faus The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.
