So, Joe, I am not using Dyna Forms, just plain old form beans. (I may refactor my DTOs/VOs and form beans into some base class because of all the shared fields, but for now, I'm getting a lot of use out of a bean generator I wrote). Are you agreeing then, that the best approach (currently) is to create an action for the view screen (in this case, the "update" form page), and in that action, obtain a VO and use the values from that to set the properties of the ActionForm? You are saying if I do this I need to explicity set a key to the form as a request attribute? (Somehow I assumed that the form already would be set as an attribute and that all I would need to do is modify the values of it).
Thanks again, Erik
Joe Germuska wrote:
In my experience, it helps all involved to avoid redundancy and copying. If you logically treat inserts and updates as more "same" than "different" then you're better off making one page with conditionals. This serves as implicit documentation of the fact that they are more the same, while having two JSPs suggests that they are more different. Someone who doesn't know the details (including you in the future after your next project crowds out the details of this one) will understand better if you only duplicate things when there is a good reason for it. In my personal taste and experience, avoiding conditional logic blocks in a form isn't a good reason for it.
As for performing the pre-population, this is somewhat cumbersome. If you are not using a session-scoped form, then it is somewhat tricky to get a handle on the "output form" which needs populating. The Struts "execute" signature passes in an "input form" based on request parameters. Even if you were using session scoped forms, this assumes that you want to use the same form bean for input and output, which is often not the case.
If your form bean is a simple non-dynamic form, then it's not too big a deal to instantiate the bean, populate it, and put it in request or session scope under the "name" attribute associated with the action which receives the form submission. This is the bare minimum to do to "make it work." If you're using DynaForms, it's a little harder to get an instance.
In the Struts 1.3 timeline, I'm hoping to work on some things to make this easier. If you are interested in the details and in being on the "bleeding edge," feel free to subscribe to the [EMAIL PROTECTED] list where this would be discussed/critiqued/etc. I can't use the pending release of 1.2.1 as an excuse any more, so now I just have to squeeze time into my schedule to get started.
Joe
At 10:31 AM -0400 7/12/04, Erik Weber wrote:
Hello. I want to solicit some advice and opinions. Working on my first Struts app.
I have some use cases that call for typcial "add" and "update" functionality that basically can share the same forms. Obviously when the form is first displayed under "add" conditions, it needs to be blank. Under "update" conditions, the form needs to be prepopulated using the results of a DB select. In addition, a few fields that are present under "add" conditions no longer should be present under "update" conditions.
My current plan is to:
1) Use two different JSPs to house these forms, even though there will be a lot of redundancy, because the fields may have some variation, and because I'm not fond of having conditionals in the form (if (add) { } else { //must be update). I suppose the common block of fields could be refactored into an include. Any opinions on this are welcome.
2) Prepopulate the "update" form by assigning an action to it. I suppose the action would, in the execute method, call a business object, get a value object and use the attributes of this object to set all the fields of the ActionForm before returning a forward to the update form screen. Is this the right approach? I would especially like opinions here. My view screens have ".jsp" extensions but my screens that have submittable forms have actions that use path mapping, such as "foo/login" and "foo/register" and "foo/save", and so forth. Is it common to map viewing/prepopulating actions one way and saving/writing actions another?
I have heard of the use of the "reset" method in an Action for prepopulating a form, and indeed it looks convenient. I also have heard Struts developers may want to deprecate this method.
Any advice/opinions/links welcome.
Thanks,
Erik
--------------------------------------------------------------------- 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]
