struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <mart...@apache.org>
Subject Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?
Date Tue, 03 Feb 2004 02:59:49 GMT
I can't read Craig's mind ;-) , but I would say that the main reason an
ActionForm's constructor doesn't get passed the request (or anything else)
is because it is (intended to be) a form *bean*. One of the primary
characteristics of a JavaBean is that is that it must have a no-args
constructor. That allows it to be instantiated from anywhere. Passing a
request instance to the constructor presupposes that an ActionForm is
constructed only in the context of a request.

A secondary reason, in my mind, is that passing a request to the constructor
would encourage people to stash it away as member data, which would not be
too cool if the bean was created in session scope...

--
Martin Cooper


"Jeff Skubick" <jeff.skubick@mci.com> wrote in message
news:003a01c3e9dd$43229550$92a238a6@mcilink.com...
Is the absence of a reference to the HttpServletRequest object that
triggered the creation of a new ActionForm object in its constructor a
historical artifact or oversight, or was it an intentional decision whose
motivation and rationale remains 100% valid and relevant today?

At the moment, I'm in a quandry. I see no way to usefully use nested form
beans to encapsulate administrable users in my web app without somehow
getting a hold of a list of objects representing those administrable users
from the session context of the user who's administering them (the list's
composition depends partially upon the user doing the administration) so I
can prepopulate the list for its initial display.

On the other hand, I'm worried that ActionForm's original creator was
absolutely determined to keep ActionForm's constructor from ever knowing
anything about the user or request that triggered its creation in the first
place for some reason, like Struts casually re-using old ActionForm
instances to satisfy new requests. On the other hand, I know it might just
be a historical artifact that seemed like a good idea at the time, but
doesn't really have any major implications either way.

So... if I implement my own RequestProcessor class that overrides the
default processActionForm method to call my own ActionForm-extending bean's
constructor an explicitly pass it a reference to the HttpServletRequest
object so it can fetch the HttpSession object and find the object that tells
it everything else it needs to know to pre-populate the form bean prior to
display, am I violating any sacred assumption made by other parts of Struts?
Or am I OK?




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message