You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Deadman, Hal" <ha...@tallan.com> on 2001/02/21 00:28:17 UTC

RE: help! confused over forms and errors and oooh, other stuff :- )

I don't know if I understand your question but would making the input
attribute of the action another action give you the opportunity to retrieve
data that the jsp form needs before the jsp is displayed? I have a form that
needs a drop down populated from the database before the form is displayed.
I can never go to the jsp form directly, I always reference the action that
gets the data needed by the jsp. The action returns a forward which forwards
to the jsp with redirect="false". 

Hal

-----Original Message-----
From: Ned Seagoon [mailto:therealneddyseagoon@hotmail.com]
Sent: Tuesday, February 20, 2001 6:06 PM
To: struts-user@jakarta.apache.org
Subject: Re: help! confused over forms and errors and oooh, other stuff
:-)



Can nobody give me a clue as to whether I've missed something here? I have
to do a 'show and tell' session on friday where we probably will be deciding
whether to use struts as the basis of future developments. If I'm going to
have to branch away from struts to handle these issues, so be it, but I'd
rather hope they were handled somewhere. Worst case scenario is that we
don't use struts at all.

Regards
Ned

----- Original Message -----
From: "Ned Seagoon" <th...@hotmail.com>
To: <st...@jakarta.apache.org>
Sent: Tuesday, February 20, 2001 11:47 AM
Subject: help! confused over forms and errors and oooh, other stuff :-)


> Hi Guys,
>
> I wonder if you could help me out a little please? I am in the middle of
> developing a proof of concept app with struts. If this comes off the
company
> could migrate away from a proprietary framework to struts, which I am in
> favour of.
>
> I seem to have confused myself over an issue regarding validation and
forms.
> I’ll give a simplified workflow as an example.
>
> We have for all intents and purposes a generated product overview page
along
> these lines:
>
> *Wooden Throat Mallet        59.95 >buy<
> *Leather Uncle Frightener    12.60 >buy<
> *Vandal-Proof Toupee         99.99 >buy<
>
> Which is generated from struts tags. The >buys< are links to a pages which
> look something like ‘buyit.do?itemid=50’. The buyit.do action has
registered
> a form in request scope. During processing, it looks up the full details
of
> the itemid and places the resulting bean in request scope. It then creates
> the form object, populates it with some default information and sets this
in
> the request too before forwarding onto buypage.jsp
>
> This displays the details of the item, and contains a form for entering,
> say, credit card details:
>
> *Item: Vandal-Proof Toupee
> *Manufacturer: Lockheed-Martin Advanced Hairpiece Research
> *Price: 99.99
> *Additional Information: Also Invisible to Radar
> *
> * Inside Leg Measurement: _____
> * Credit Card Number: ____________________
> * >BUY< {forwards onto checkout.do}
>
> Which is all fine and dandy and displays correctly. Though what happens if
> the form validate fails? If checkout.do has an ‘input’ attribute which is
> buypage.jsp then this will fail because the item details are stored on the
> request has not been set up (it was done in ‘buyit.do’). I could of course
> set the item details on the session, but if the user opened new browser
> windows for the ‘buyit’ link, then the session level object will be
> overwritten.
>
> If have looked into placing the details object onto the form bean as it is
> populated, but will that property be preserved across a validate failing?
> And how do I get at the properties of the form bean outside of the
> <hmtl:xxx> tags?
>
> Help !
>
> Regards
> Ned
>
>
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>

Re: help! confused... now contains a proposal

Posted by Ned Seagoon <th...@hotmail.com>.
> Ned Seagoon wrote:
> > I reckon the way to approach this is to modify ActionForm handling. I
would
> > add a field to this which holds the HttpServletRequest which gets set
when
> > the form is created/retrieved in ActionServlet.processActionForm.


From: "Craig R. McClanahan" <Cr...@eng.sun.com>
> Are you planning on keeping this reference to the HttpServletRequest
object past
> the end of the current request?  If so, you are pretty much guaranteed to
have
> problems on any servlet container (such as Tomcat) that recycles request
and
> response objects.  The 2.3 servlet spec is also likely to clarify that
it's not
> legal to maintain references to the request and response objects after
your
> servlet's service() method returns.

D'oh! Oh yes, of course. I was thinking of keeping the request around so
that in a function like setItemId it could use the request to do a lookup
for any information and set it into the form bean. Fine, I'll just change
the populate() function to take the HttpServletRequest there.

This pattern works, I modified ActionServlet.ProcessValidate so that if the
validation fails, a class cast is attempted and populate() called on the
form. This then picks up the required object from the session (via the
request) and stores it in the form, ready to be displayed by the view.

So what do you think? Is this worthy of being incorporated? Maybe this
solution is not correct, but there is definately a need for what it is
fixing...

regards
Ned.

Re: help! confused... now contains a proposal

Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ned Seagoon wrote:

>
> I reckon the way to approach this is to modify ActionForm handling. I would
> add a field to this which holds the HttpServletRequest which gets set when
> the form is created/retrieved in ActionServlet.processActionForm.

Are you planning on keeping this reference to the HttpServletRequest object past
the end of the current request?  If so, you are pretty much guaranteed to have
problems on any servlet container (such as Tomcat) that recycles request and
response objects.  The 2.3 servlet spec is also likely to clarify that it's not
legal to maintain references to the request and response objects after your
servlet's service() method returns.

The alternative would be to copy the request parameters into some private
structure if you need to repopulate later.

Craig



Re: help! confused... now contains a proposal

Posted by Ned Seagoon <th...@hotmail.com>.
Hi Hal, thanks for your mail

Yep that would be one solution if the population if the bean required on the
form page was 'static', but in the case I was referring too it needed the
item id to look up. I would imagine that it might be done by sending
actionforms with the id in backwards and forwards but this would become a
maintenance nightmare.

I reckon the way to approach this is to modify ActionForm handling. I would
add a field to this which holds the HttpServletRequest which gets set when
the form is created/retrieved in ActionServlet.processActionForm. The
ActionForm should also have a method called something like populateForm()
which the user developer could override to retrieve any values required from
sessions/databases etc. This would be called automatically when
formValidation *fails* and is probably better left to the developer to call
from Action.performAction if validation succeeds. My example would then be
along the lines of:

ActionForm {
    ... other stuff...

    HttpServletRequest request;
    void setRequest(HttpServletRequest r) {.....}
    void populateForm() {}
}

MyOrderActionForm extends ActionForm {
    String itemId;
    Object item;

    // get/set item id and get/set item omitted

    void populateForm() {
        ItemMap map= (ItemMap) request.getSession.getAttribute("item map");
        item = map.get(itemId);
    }
}

and for the buyit.do action (remember, called from /buyit.do?itemid=52)

perform(.....) {

    MyOrderActionForm form = new MyOrderActionForm();
    form.setItemId( request.getParameter("itemid") );
    form.populateForm();

    request.setAttribute("orderform", form);

  return mapping........
}

And on the view, the object bean could be got from the form for displaying.

Any thoughts?

It would be better to place this into the ActionForm class and do it
properly, but I'll wait until the feature freeze is over before trying to
submit it. In the mean time i'm going to have to derive my own classes and
override functions.

Regards
Ned

----- Original Message -----
From: "Deadman, Hal" <ha...@tallan.com>
To: <st...@jakarta.apache.org>
Sent: Tuesday, February 20, 2001 11:28 PM
Subject: RE: help! confused over forms and errors and oooh, other stuff :- )


I don't know if I understand your question but would making the input
attribute of the action another action give you the opportunity to retrieve
data that the jsp form needs before the jsp is displayed? I have a form that
needs a drop down populated from the database before the form is displayed.
I can never go to the jsp form directly, I always reference the action that
gets the data needed by the jsp. The action returns a forward which forwards
to the jsp with redirect="false".

Hal