On Fri, 22 Nov 2002, Thomas Heller wrote:

> [ posted to struts-user but i just realized struts-dev might be a better
> place for this]
>
> Hi there,
>
> I'm trying to create a form with some pre-filled which either come from a
> cookie or a database. i browsed the archive and found a comment from Craig
> where he says the best way to do this is by routing the specified request
> into a action and populate the form there. IMHO this way would complicate
> the Actions execute method unnecessary complicat cause it must have a
> "action-case" for "prepopulate".
>
> IMHO the best way to handle what i would want to do would be done like this.
>
> 1. introduce a "prepare(HttpServletRequest request)" method info
> "ActionForm"
> 2. invoke this method in "RequestUtils.createActionForm(...)" right after
> "instance.setServlet(servlet)" in line 638

I agree with Eddie that you really should be doing this work in an action.
Even if you did have a prepare() method, this certainly isn't where you
would want it to be called, and there's nowhere else Struts could call it
that would make sense.

The problem with calling it here is that I really don't think you want to
be going through all the trouble of filling out the form fields right
before Struts overwrites them with the parameters of an incoming request.
Remember that form beans are created for you when a request comes in, and
your prepare() method would be called then too.

--
Martin Cooper


>
> inside the Forms "prepare" (populate or some other name) Method i could
> prepare all fields like i want including setting values from session,
> request, cookies, context, db, etc since i get the current request as a
> method param.
>
> dunno how to submit patches to struts but it would look something like this:
>
> class: org.apache.struts.action.ActionForm
> [snip]
>
>     /**
>      * Prepare the form before it gets displayed first.
>      * <p>
>      * The default implementation does nothing.  Subclasses can
>     * override this method to insert values from a DB/Cookie into
>     * the form
>      *
>      * @param request The servlet request we are processing
>      */
>     public void prepare(HttpServletRequest request) {
>
>         ;       // Default implementation does nothing
>
>     }
> [/snip]
>
> All forms written before this method would still work and it eases the work
> of setting form values by cookies alot.
>
> Comments welcome ...
>
> thanks,
> Thomas Heller
>
> > Date: Tue, 25 Jun 2002 20:17:35 -0400 (EDT)
> > From: Matt Barnicle <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: Playing with cookies - How?
> >
> > Thanks again, Chris.  This helps me out a bit, but I'm still clueless on
> > how to take the cookie value to pre-populate the form.  I know I could
> > come up with some way to rig it, like:
> >
> > <html:radio name="foo" value="1"
> >   <logic:equal name="mycookie" property="value"
> value="1">checked="checked">
> >
> > But that seems to defeat the usefulness of Struts, and I'm sure there's a
> > more appropriate way to do it.  How?
> >
>
> This kind of syntax actually won't work anyway -- you cannot nest an XML
> tag inside an attribute value.
>
> IMHO, the best way to deal with situations like this is the same as any
> other situation where you need to pre-populate a form -- route the
> incoming request through an Action that pulls out whatever you need from
> your cookies and uses it to populate beans that are later used by the JSP
> page that you forward to.
>
> The struts-example application uses this design pattern (although with a
> database lookup instead of cookies) when you select the "edit your
> profile" option.  This is routed through the /editRegistration action,
> which looks in the pseudo-database and prepopulates the form bean for the
> registration form.
>
> Craig
>
>
> --
> To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to