On 7/6/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > 1) The person asking I believe was a beginner to Struts. Suggesting to > have a DAO used in ActionForm is something definitely unorthodox and > since the person is new to the framework it is unlikely he'll see many > examples of this and it can get confusing if he's seeing things done in > some non-orthodox way.
I would agree with that. > 3) You asked what the purpose of the ActionForm was for and first off I > must state that I don't like the tie in of ActionForms with Struts. I > like the approach JSP takes much better, but since I'm working with > Struts here the purpose as I understand it is mainly a) To have a tie in > to the html:form tag for pulling out properties using the html tag and > b) for providing a mechanism to ensure the user's input remains for when > validation fails and you are returned back to the page. So, you use action forms both for input and output. This is great. Change the scope to "session", throw in some methods, and you get yourself a backing bean. This is what it should be. > There has been > debate on this list as to where exactly the ActionForm fits in the > architecture, but rarely have I seen it debated that it should serve up > business logic making calls to the backend. The typical design rule is > usually separation of responsibilities. If you now start having > ActionForms deal with making calls to your persistence layer, you know > just added one more layer to have to maintain this code. I don't think so. Both action form and action class belong to web/presentation layer, so it does not make a difference for me where to put my code. If, instead of having two classes, Struts had only one class like Webwork, in which action can be stateful, then you would not have any doubts, would you? So consider action class and action form as part of what could be one class. > Granted, you > could make things 'sort of' clean by making sure to call some delegate > or facade that hides the backend call, which I like to do anyway in my > Action classes. Yep, me too. So, two lines of code here or there do not make a difference. > 4) Since the ActionForm is used to capture user inputted data, it seems > against the grain to have the ActionForm itself populating a state that > the user wants to edit. I don't have this feeling, but I am not suggesting a new universal rule to access persistence layer from action form. I am merely saying that if it works, why not? > Also, typically ActionForms aren't just used to > capture 'edit' data but also data for a fresh "add" operation. So now, > not only have you added backend calls from your ActionForm, but you now > added more complex logic to have to decide when to make those calls and > when not to (is the form being used for an edit operation or for a fresh > add operation?) Actually I'm not even sure how you would accomplish > this? You tell me - how are you going to know it's an 'add or edit' > operation while in the reset method? You aren't going to want to > populate all the employee/user info if it's an 'add', yet somehow you'll > have to know this? I guess you'll have to use request.getParameter > because you won't be able to use the form fields since they don't get > populate until 'after' the reset is called. So you see the kind of mess > things become? Um, author of original email did not provide any further information on whether this form is used for 'add' too. I supposed, that it was used for editing existing object, and for redisplaying entered data if it is incorrect. To redisplay invalid user data it must not be overwritten by pre-loaded data, thus reset() seems as simple and easy way out, though you may think that it is simple and dirty way out ;) About 'add' and 'edit'. I have two versions of same approach. First, that I used before I switched to DispatchAction, was to replace 'add' with 'create' and then 'edit': first I create empty object using create action, then I redirect to edit action, which shows whatever is in the form bean. Therefore a form bean always works with existing object, either loaded from database or just created. The simplification of this approach is using of dispatch action and redirecting from it to itself. Commands like 'create', 'edit', 'view' are dispatched to handlers, which load or create an object, then handlers redirect to the same action, which displays whatever is in the form. See details here: http://struts.sourceforge.net/strutsdialogs/crudaction.html All CRUD operations are neatly provided by one class, but of course it should be backed by an action form, which does the dirty work ;) > You have to tell the new person.. "Oh wait, don't use the > form field here to determine if it's an edit or add, because that > property hasn't been populated yet." > 5) Another problem is consistency. Most users of Struts understand that > they submit a form and it goes to an Action and then you forward > somewhere. Pretty basic. I would rather tell the new person, use Struts Dialogs, this is so much simpler than to invent everything yourself, which you have to do becuase Struts is so basic. > So imagine the person that inherits the code > where the edit information is done by the ActionForm itself... the > developer sees himself click the "edit this employee" button and a form > page comes up populated with the employees info to edit. He realizes > something is a bit wrong and he needs to debug the app. More than likely > he's going to look first at the Action the form submits to since that's > what most of the forms do... but low and behold, he/she doesn't see > where the population of the form is taking place since it's being done > in the ActionForm itself. Documentation, javadocs, and it is not a big deal to relate two classes, using action mapping definition in the config file. > You save nothing doing prepopulation in a reset > method versus an Action As I already said, this allows to overwrite pre-populated values with request values, not vice versa. Nice to have when the same form is used for redisplaying entered data. >so I'd argue to be consistent with how people > expect to use the framework - especially when giving advice to a newbie. You are right on that. Which is why I developed my library, so newbies can save efforts creating UI. Why would not you take a look at it? But it may seem a little unorthodox for you at first ;) Michael -- Dialogs for Struts http://struts.sourceforge.net/strutsdialogs --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
