Re: help with a newbie topic-prepopulating a form
On 7/5/05, Rick Reumann [EMAIL PROTECTED] wrote: Michael Jouravlev wrote the following on 7/6/2005 1:11 AM: On 7/5/05, Rick Reumann [EMAIL PROTECTED] wrote: Use the reset method only for doing things like making sure some boolean fields are set to false. I highly recommend you DO NOT use the reset for 'business type' logic. Having a few default things set there is fine, but for stuff like you are suggesting, you do that in an Action class or DispatchAction method BEFORE you forward to the page. Any particular reason for that? Also, if default values are set in reset(), they will be overwritten by request values if there are any. Right. That's what you *want* to happen - otherwise what would be the point of reset if it never let the user's input overwrite the form's default values? Reset() is called first by struts *then* the form gets populated with any request parameters that match the form properties. Right. This is why reset() is a good place for init values. If there are no request values, init values will be used. Usually, this is the preferred scenario. If values are set right before rendering a page, then request values will be overwritten by default values. NO this does not happen when you leave an Action and forward to a page. It only happens on submit. Are you saying that submit and render operations are served by different actions? Original author did not imply that. Maybe you are confusing 'default' values that the form has with 'pre-poulated' values. A form that is used to edit user information, like the original poster mentioned he wanted, are 'pre-population' values - those you would never want to set in a reset (or even worse a validate) method. I do not see any difference between default and pre-populated values. These are values which are set in HTML form before a user gets chance to change them. I do not care where these values come from: from a property file or a database. Are you suggesting it's a good idea to call business logic (DAOs etc) in order to populate a form bean with information such as an Employee name or Address? Hopefully it's just late and I'm misunderstaning you and you are not saying this:) Why? What is the difference of calling DAO from action class or a form bean? They are used in pair anyway. If by some chance you are, PLEASE do not advise the newbies to do this. This totally defeats the pupose of what ActionForms should be used for and will create all kinds of maintenance headaches, never mind the fact that it's really bad design. Can you explain why is it so bad, besides that it is bad design and defeats pupose of what ActionForms should be used for? What ActionForms should be used for, anyway? It is just a class, which has a simple lifecycle, maintained by Struts. Why the religious fear of not doing something against how it should be used for? If it works, why not? Typically for an edit scenario that the user mentioned, you'd click on a link with a userID, go to your Action, look up the UserObject from backend based on userID, populate your ActionForm with the user information, forward to the page to now alow the information to be edited and submitted. I do almost the same, but because my form bean is used for output only, that is, to prep the JSP, I can stick all code into form bean and forgo action class altogether. Standard ForwardAction works well, but I would prefer if I could return forward mapping right from the form bean. Now, this object is presented to a user, he makes changes, where the request goes? To the same action or to a different one? If to the same, then request values must not be overwritten by pre-populated ones from database. In your example they will be. Whatever, I have a separate initialization event, which signals to the component to pre-populate data. In other cases I use whatever is currently retained in a form bean, which has session scope. Form bean with session scope works like a simple object cache. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
Michael Jouravlev wrote the following on 7/6/2005 3:22 AM: Can you explain why is it so bad, besides that it is bad design and defeats pupose of what ActionForms should be used for? What ActionForms should be used for, anyway? It is just a class, which has a simple lifecycle, maintained by Struts. Why the religious fear of not doing something against how it should be used for? If it works, why not? Obviously different people will have different ideas for how they should do things and there is something to be said for hey if it works why not, but here are some things to consider... 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. (Granted 'orthodox' doesn't always equate to best-practice, but I'll get into why I think it's bad in some other points). 2) Not only is more difficult for a beginner to start doing things in an unorthodox way, it also will be more difficult for someone else that would have to inherit the code to understand. Poll all the gurus that have been doing Struts for many years and ask them if they'd ever expect to see database calls from within an ActionForm. Now, putting the above aside, here are some reasons why it's poor design... 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. 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. 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. I think it's a good design practice to try to limit where types of calls are being made. By moving backend calls to the ActionForm you've added a whole other layer to have to maintain those calls (other than say just Actions). 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. 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? 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. 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. 6) Why not have all your forms simply submit to the generic ForwardAction and you can do all the logic in the reset, not just pre-population? You can pull out request parameters and then do what you need to do there... call updates, inserts, whatever. Actually I'd recommend doing this over doing some of this in
Re: help with a newbie topic-prepopulating a form
On 7/6/05, Michael Jouravlev [EMAIL PROTECTED] wrote: If by some chance you are, PLEASE do not advise the newbies to do this. This totally defeats the pupose of what ActionForms should be used for and will create all kinds of maintenance headaches, never mind the fact that it's really bad design. Can you explain why is it so bad, besides that it is bad design and defeats pupose of what ActionForms should be used for? What ActionForms should be used for, anyway? It is just a class, which has a simple lifecycle, maintained by Struts. Why the religious fear of not doing something against how it should be used for? If it works, why not? Here's the last paragraph of the JavaDoc for the reset() method (emphasis in original): This method is *not* the appropriate place to initialize form value for an update type page (this should be done in a setup Action). You mainly need to worry about setting checkbox values to false; most of the time you can leave this method unimplemented. You say the ActionForm is just a class with a simple lifecycle. That lifecycle is more than just a sequence of method invocations, but also the expected behavior of each of those invocations. The documentation (lifecycle specification) clearly defines that the only behavior that is expected during the invocation of the reset() method is to set checkbox values to false. -- Jeff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
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
Re: help with a newbie topic-prepopulating a form
On 7/6/05, Jeff Beal [EMAIL PROTECTED] wrote: Here's the last paragraph of the JavaDoc for the reset() method (emphasis in original): This method is *not* the appropriate place to initialize form value for an update type page (this should be done in a setup Action). You mainly need to worry about setting checkbox values to false; most of the time you can leave this method unimplemented. You say the ActionForm is just a class with a simple lifecycle. That lifecycle is more than just a sequence of method invocations, but also the expected behavior of each of those invocations. The documentation (lifecycle specification) clearly defines that the only behavior that is expected during the invocation of the reset() method is to set checkbox values to false. -- Jeff Jeff, I don't have a blind faith in word written by someone whom I have not even had a drink with. ;-) Michael. -- Dialogs for Struts http://struts.sourceforge.net/strutsdialogs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
On 7/6/05, Michael Jouravlev [EMAIL PROTECTED] wrote: Hmm, the description for CRUDAction does not have a link to the live demo. Here it is: http://www.superinterface.com/strutsdialog/cruditemlist.do This one uses two separate actions: one for the list and another for all crud operations. Thus, browser keeps accumulating history, which is not very clean. There is another version which uses one action for everything, it behaves like a single-page application. It is not online yet. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
On 7/6/05, Michael Jouravlev [EMAIL PROTECTED] wrote: On 7/6/05, Jeff Beal [EMAIL PROTECTED] wrote: Here's the last paragraph of the JavaDoc for the reset() method (emphasis in original): This method is *not* the appropriate place to initialize form value for an update type page (this should be done in a setup Action). You mainly need to worry about setting checkbox values to false; most of the time you can leave this method unimplemented. You say the ActionForm is just a class with a simple lifecycle. That lifecycle is more than just a sequence of method invocations, but also the expected behavior of each of those invocations. The documentation (lifecycle specification) clearly defines that the only behavior that is expected during the invocation of the reset() method is to set checkbox values to false. -- Jeff Jeff, I don't have a blind faith in word written by someone whom I have not even had a drink with. ;-) Michael. -- Dialogs for Struts http://struts.sourceforge.net/strutsdialogs I never asked you to go on blind faith -- I quoted the documentation. Let me do it again: This method is *not* the appropriate place to initialize form value for an 'update' type page. I don't know what word could be more authoritative than the documentation. If it is my words that you don't have blind faith in, than I guess you never will -- I don't drink. ;) -- Jeff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
Michael Jouravlev wrote the following on 7/6/2005 12:26 PM:
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.
Well, not really. I should be able to use a POJO/ValueObject not tied to
Struts packages. A true backing bean could be used on the backend and
front interchangeably. Sure, if I wanted to tie my entire backend to
Struts I could be passing around the ActionForm everywhere, but I don't
really like doing that (the whole seperation thing again:).
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.
I have considered this, and again this is another reason I consider the
ActionForm the ugly duckling of Struts:)
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?
One of the reasons is I'm not sure (like I mentioned below) how you
reuse this ActionForm under different situations... I often use the same
ActionForm in many diffrent cicumstances. I wouldn't want it always
being populated (the add was just one example) so you'd need a
mechanism to decide when and when not to call the populate and, not only
that, but what gets populated might need to change based on what the
ActionForm is being used for. For example, you might have a generic
UserForm (name and ID - for simplicity)- this form might sometimes be
used for dealing with Accounting users or sometimes HR Users. In order
to resuse this form in many different circumstances you'd have to have a
bunch of conditional logic in your ActionForm. I find it cleaner to
avoid that logic. I find it cleaner to bind that userForm to different
ActionMappings and thus the resulting Action takes care of knowing what
to do, vs putting all the responsibility on the ActionForm knowing how
to populate itself.
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 ;)
Well, he didn't state he needed it for an add but I think an
ActionForm should be flexible enough to support it. (I doubt you'd make
a POJO that could be used in 'one way'.
In regard to To redisplay invalid user data it must not be overwritten
by pre-loaded data, thus reset() seems as simple and easy way out.., I
must be confused on what you see happening that I don't. I don't use the
reset to pre-populate the form data and never have a problem with
anything being over-ridden when valiation fails (There is the problem of
request scoped forms that have lists on the page that need to be reset,
but that's another topic:).. and I wrote the solution I like
here..http://www.reumann.net/struts/articles/request_lists.jsp ).
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 ;)
Guess I'm too old skool, I like the dirty work called from my Action
dispatch (CRUD) methods. So I might have...
setUpForEdit(...) {
Employee emp = service.getMeEmployee(someID);
PropertyUtils.copyProperties( (EmployeeActionForm)form, emp );
//...
}
edit(..) {
Employee emp = new Employee();
PropertyUtils.copyProperties( emp, (EmployeeActionForm)form );
service.updateEmployeee( emp );
//...
}
add(..)
seems pretty clean to me and his been doing the job quite effectively.
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.
I'll have to check out Struts Dialog sometime.
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 ;)
Sounds good.
Re: help with a newbie topic-prepopulating a form
Michael Jouravlev wrote: The only book I would follow without asking for explanation would be a nuclear power station operator's manual. In all other cases I have time to sit down and think things over. Strictly speaking, you shouldn't actually be operating a nuclear power station without already having read the manual and asked those questions... (My Dad used to be the guy they asked, but I imagine a fair number of his students graduated to actually working in power plants without a clue about the why of any of it). -- derek - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
On 7/6/05, Adam Hardy [EMAIL PROTECTED] wrote: Now there is talk of Struts in the future containing ActionCommands which can be substituted in place of Actions, and strung together in a chain, and presumably can perform View-Controller logic. If you look at Shale (with its support for both ViewController and Dialog -- which, among other things, lets you intersperse action states and view states to your heart's desire), you'll find that the future is now :-) http://struts.apache.org/shale/ Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
On 7/5/05, Tony Dahbura [EMAIL PROTECTED] wrote: Team: I am trying to pre-populate a form before letting the user enter/correct data in it. The only way I have seen to do this is to actually do this prefilling fields in the reset method of the actionform. I am not sure this is the place to do this. For instance I have a form that lets user edit their profile and I want to pre-populate with their name and phone number etc...Should I do all this in the form's actionForm reset method or where? Hey boss, you did not give your team enough details on your configuration, so I can just assume that you are sending request to action mapping, and then display JSP page using values from an actionform. So, here is the standard sequence: ActionForm.reset() / populate ActionForm from request / ActionForm.validate() / Action.execute() if no errors returned from ActionForm.validate() / render JSP. So, if you are expecting request data, you have to decide what takes precedence: request data or your data. If request data wins, then you initialize your actionform in reset(), and it will be updated with request values if any when actionform is populated with request values. If default values win, than you initialize your actionform in validate() (if you do not define custom action class) or in action class. Catch: if you action form has request scope, then reset() may (will?) not be called, so I would call reset() manually from the constructor. Another catch: if you use the same action both to initialize your form and to accept user input, than you need to distinguish somehow between these two modes: when you are presenting the form for the first time, and when you are accepting input and (maybe) re-rendering the form with current data and (possibly) with error messages. Hmm, I guess putting default values in reset() seems more logical. Michael -- Dialogs for Struts, http://struts.sourceforge.net/strutsdialogs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
On 7/5/05, Rick Reumann [EMAIL PROTECTED] wrote: Use the reset method only for doing things like making sure some boolean fields are set to false. I highly recommend you DO NOT use the reset for 'business type' logic. Having a few default things set there is fine, but for stuff like you are suggesting, you do that in an Action class or DispatchAction method BEFORE you forward to the page. Any particular reason for that? Also, if default values are set in reset(), they will be overwritten by request values if there are any. Usually, this is the preferred scenario. If values are set right before rendering a page, then request values will be overwritten by default values. Michael. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: help with a newbie topic-prepopulating a form
Michael Jouravlev wrote the following on 7/6/2005 1:11 AM: On 7/5/05, Rick Reumann [EMAIL PROTECTED] wrote: Use the reset method only for doing things like making sure some boolean fields are set to false. I highly recommend you DO NOT use the reset for 'business type' logic. Having a few default things set there is fine, but for stuff like you are suggesting, you do that in an Action class or DispatchAction method BEFORE you forward to the page. Any particular reason for that? Also, if default values are set in reset(), they will be overwritten by request values if there are any. Right. That's what you *want* to happen - otherwise what would be the point of reset if it never let the user's input overwrite the form's default values? Reset() is called first by struts *then* the form gets populated with any request parameters that match the form properties. Usually, this is the preferred scenario. If values are set right before rendering a page, then request values will be overwritten by default values. NO this does not happen when you leave an Action and forward to a page. It only happens on submit. Maybe you are confusing 'default' values that the form has with 'pre-poulated' values. A form that is used to edit user information, like the original poster mentioned he wanted, are 'pre-population' values - those you would never want to set in a reset (or even worse a validate) method. Are you suggesting it's a good idea to call business logic (DAOs etc) in order to populate a form bean with information such as an Employee name or Address? Hopefully it's just late and I'm misunderstaning you and you are not saying this:) If by some chance you are, PLEASE do not advise the newbies to do this. This totally defeats the pupose of what ActionForms should be used for and will create all kinds of maintenance headaches, never mind the fact that it's really bad design. Typically for an edit scenario that the user mentioned, you'd click on a link with a userID, go to your Action, look up the UserObject from backend based on userID, populate your ActionForm with the user information, forward to the page to now alow the information to be edited and submitted. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
