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 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 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.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.
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]
