I'm not sure what your proposing is bad per se... let's ask it this way:
how else could you accomplish this without manually instantiating the
form, because I agree, that's the one part that doesn't smell great to
me either.
One way to do it would be that the forward returned from Page1Action
specifies not a JSP directly, but instead some "setup" action mapping
for page2. It would have the session-scoped form mapping, so Struts
would create it if necessary, and the action could then do the necessary
populating that page2.jsp requires.
That's probably a somewhat cleaner approach, but it has the down side of
invoking the whole request processing cycle again, so there is an
overhead involved. Bit of a trade-off.
FYI, just for another opinion, I don't like the idea of using business
objects directly in the view. To me, an ActionForm has a very
well-defined job: it is a DTO between the view and the control layer.
It should deal with string only, since that's what you get with HTTP,
type conversions should be handled downstream. I DO think it should be
used for both input and output. I realize this leads to more code, more
classes, but I think the original point of ActionForm was a good
decision, to me it doesn't feel right that so many people are in favor
of moving away from that (I'm not even sure I like the combined
Action/ActionForm you get in S2... I'm still mulling that one over in my
warped little mind). It's just my opinion though.
Frank
Chaudhary, Harsh wrote:
I am not doing things this way. I presented this as a hypothetical case
and my question is why is this bad? I mean what problems can we run into
using this technique.
Thanks for the write up but I would appreciate something that in more in
detail.
Thanks,
Harsh.
-----Original Message-----
From: Michael Jouravlev [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 28, 2007 3:32 PM
To: Struts Users Mailing List
Subject: Re: Struts session scoped forms
On 2/28/07, Chaudhary, Harsh <[EMAIL PROTECTED]> wrote:
I have page1.jsp which has a form which calls Page1Action which
forwards
to page2.jsp. Also, session scoped Page1Form and Page2Form.
In Page1Action, I do:
Page2Form frm = new Page2Form();
frm.setSomeVariable("Some Value");
Then read this value in page2.jsp to display.
I feel the bad part is initializing the Page2Form myself. This works
correctly because I think Struts checks for the form being available
in
all scopes, finds it in session, and just uses that instead of
creating
a new one in the Page2Form constructor.
Is this way of doing things correct? If not why? Or am I zoned out too
much to make sense?
This is okay. Not great to my taste, but okay. You should use the same
key as "name" attribute in the action mapping. I would recommend you
another pattern, but I will not going to share my way of doing this
until a new version of Struts1 that would allow to turn off automatic
reset/populate of a form is released.
Why would you create an ActionForm for pure output purposes? You can
create a POJO or even access properties of your business object.
On a side note, in Struts actions precede pages. An action receives a
request and then displays a page. In your case, it obtains information
from page1, but it renders page2. Even this is not true. An action
does not obtain information from a page, it just receives a request
and it does not care where the request comes from. So talking in terms
"page1.jsp calls Page1Action" is not entirely correct to me. Therefore
I would name your action as Page2Action, not Page1Action, that would
be clearer for me.
Michael.
---------------------------------------------------------------------
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]
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM/Yahoo: fzammetti
MSN: [EMAIL PROTECTED]
Author of "Practical Ajax Projects With Java Technology"
(2006, Apress, ISBN 1-59059-695-1)
Java Web Parts - http://javawebparts.sourceforge.net
Supplying the wheel, so you don't have to reinvent it!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
