Hello again Daniel, I'm not as experienced with OO development in general as you are, but let me elaborate on the approach I took with Struts. It isn't as clean as an implementation might be with some of the other design patterns you discuss, but it is one approach. I really think it does do all of the things you listed in your scenario, so I included references to your scenario in parantheses.
The system I am working on is a simple knowledge management system. Basically each knowledge item is some metadata stored in a database, usually with an associated external file (word document, excel spreadsheet, etc). Regardless of whether you are working with a "document" or a "project" knowledge item, you have to perform the same basic actions to it: add a new item, edit an existing item, save an item, and view an item. The add and edit actions both forward to a html form, the only difference being that when you are editing you need to read in the fields from the database and pre-populate the html form (6). The save and view actions both forward to a screen where all the information about the knowledge item is displayed, along with some other associated data (6). Obviously the save action is saving data in a database, and is having the Commons Validator validate the form (2, 5). Actually I've had some trouble with the validator, but it will at least do some validation. All 4 of these different actions use the same form bean, and extends from the same abstract action class (attached) which I defined so that I would not have to re-code all this behavior. In your case delegation might be more appropriate, but inheritance works OK for the project I am working on. So basically the way I approach Struts development is that if there is one bean with similar responsibilities (I read ahead to your reply to Brandon's email) I associate it with a single DispatchAction. There are some technical differences between the fields I need in different places, but in spirit I am talking about the same chunk of data every time I use the form. Finally, the LookupDispatchAction might be more appropriate for the application you described. It's a little complicated for our project so I haven't looked into it. This would take care of picking the action based on which button was clicked (3). If it any point an exception occurs, I leave it unchecked so that I can deal with it in the <global-exception> section of the struts-config file (4). The only item I didn't hit in your scenario is (1), but that is handled automatically by HTML, HTTP, the application server, Struts, etc. and is transparent to the developer. Matt PS - The attached abstract action class is for illustration purposes only. I removed some of the code we actually use for the sake of simplicity. ----- Original Message ----- From: "Daniel Steudel" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, July 08, 2003 1:53 AM Subject: Re: Controller and Actions thx matt >I agree that you should have several actions for a single form. >Fortunately, you can do this with Strut's DispatchAction. I make extensive >use of in the project I am working on. > i honestly have to tell you i haven't heard of this opportunity. i checked it out but there are still some things i suggest as not being "best praktice". >I think everything you described in your 6 step scenario can be done with a >combination of dispatch actions, the commons validator, and Strut's >declarative exception handling. > i don't agree with you here. i also think that you can work around with this setup but it is not satisfying. again the dispatchaction is only one action which makes you infexible. i think of actions as a potion of software you can put into various contexts. best example would be a form reset action which can be put on every view to reset the userinput. as far as i can see you have to provide a reset routine in every action to do so. if the reset action would be independent it would be possible to use this action in various contexts. furthermore you have only one form an action can deal with. this means for the different contexts you have to create different forms to adequately handle the userinput. if you look at swing actions deal with input themselves. i don't think processing input like that isn't possible on the web but what about callback methods or listener methods the controller (i mean the controlling portion of a view) has to implement? another thing is to channelise comunication between the componenst (view - action - model ) through the controller (not the struts-type controller). if you do so, you can compose components more easily i'd say. DeeasS >You should check out the documentation on >Jakarta's site or purchase one of the many books about Struts. The O'Reilly >book is IMHO not so great, but at least it does a good job explaining all of >the features of Struts so at least I knew where to look. > >Matt >----- Original Message ----- >From: "Daniel Steudel" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Sent: Monday, July 07, 2003 11:19 AM >Subject: Controller and Actions > > >hi folks, >i am working on a project right now for which i figured out struts to be >perfectly suitable. but as i looked at it a little closer i saw some >issues in the "struts way" i don't agree with. the main problem is that >you think of a 1-to-1 relation between a form and an action (i think so >'cause you send a form to an (action-)controller that handles the params >and passes them to one action). i would say there could be various >actions on one form. you can have several submit-buttons each considered >as a separate action. so the action to be performed should be determined >by the value of the submit-button. > >the other thing i would expect is a 1-to-n relation between (what i >refere to as controller) a controller that handles form-data and views. >so the process would be: >1. user sends data to controller >2. controller sets up form-bean and tells the form-bean to validate it self >3. controller desides which action is to be performed behalf of the >pressed submit-button >4. action returns or fails whith an exception >5.1. on success tell form-bean to reload data and pass controll to the >appropriate view >5.2. on failure don't reload form and pass controll to the appropriate >view (to be descided on the exception) >6. view sends new content > >the point i came to this suggestion is, i have to deal with barrier-free >internet (eg lynx-compatible sites). shure you can change the location >the form is sent to by using JavaScript but not so in lynx. > >so am i completely wrong with my point of view? i would luv to know. >DeeasS > >-- >Sind Sie auch schon drin?? >Wir bieten L�sungen rund ums Internet ... > >Daniel Steudel >@-traction GbR - Informations- und Kommunikationssysteme > >www.attraction.de > >Leiterweg 43 >71254 Ditzingen > >Telefon (07156) 959202 >Fax (07156) 959201 >Mobil (0160) 7 774 271 > > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
