> On the downside, this is going to create a huge > struts-config file as there are about 40 > tables in the application.
Have you checked out xDoclet for managing your struts-config / validation.xml files? Basically the two above mentioned files will be constructed via meta-data found in your Actions/ActionForms at build time. --- "Takhar, Sandeep" <[EMAIL PROTECTED]> wrote: > 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. > > > > > __________________________________ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
