Hi all,
you can use the action in order to obtain the VO.
But a question: Are you using the html tags inside your jsp?
If yes, you can put the VO in the request and use the "value" (for
example value="${requestScope.anObject.aProperty}") attribute in the
html tags (for example "html:text).
I would like to appreciate some comments in order to use this solution.
BR
/Amleto
-----Messaggio originale-----
Da: Erik Weber [mailto:[EMAIL PROTECTED]
Inviato: luned́ 12 luglio 2004 18.17
A: Struts Users Mailing List
Oggetto: Re: Prepopulating forms
Joe, thanks for your opinion. You and Rick have convinced me to stay
with one form page for add/update. I did this before in a non-struts
app, and despite all the conditionals I ended up with, the ensuing
layout revisions did make it worth it.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
