Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Jeff Skubick <je...@mci.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?

Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Joe Germuska <Jo...@Germuska.com>]

>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?

I do think that the original intention was to have ActionForm beans 
be lightweight and no smarter than they need to be (of course, they 
do have validate() and reset() methods.)   Most Struts classes use 
no-arg constructors, following the JavaBean specifications.

Generally speaking, I'm not sure that changing the request processor 
really helps you solve your problem, as Struts doesn't really 
directly handle the idea of an "output" form -- a form populated on 
the way to displaying a page.  The ActionForm you get in an Action is 
really an "input" form wrapping the request parameters.  In some 
cases you could have an ActionMapping which used the same type of 
form bean for input and output, but practically, this is rarely what 
you need -- more often, you step from one form to the next, unless 
you use a session scoped, multi-page form bean, which can work, but 
which can behave oddly sometimes too.

On my current project, we're experimenting with the struts-chain 
request processor, which makes controlling the overall request 
process cycle much much more flexible.  We've added in a "PagePrep" 
command between "execute action" and "process forward" that looks up 
a "renderer" based on the path in the forward config and executes the 
renderer before forwarding.  The renderer configuration is not too 
different from the action-mapping section of struts-config, and 
includes a form bean name and scope for the "output" form.  It would 
be rather harder to interpose this using the strict set of extension 
points defined by the RequestProcessor, but using struts-chain, it 
was very straightforward.

Note that struts-chain is still under development -- features like 
tiles and file uploads have just been added in the last few weeks, 
and it's possible that some other things don't work quite the way 
they do using the Struts 1.1 RequestProcessor.  But it really does 
work for most things, and the more that other people use it, the 
sooner it will work for everything!

Joe
-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com    
       "Imagine if every Thursday your shoes exploded if you tied them 
the usual way.  This happens to us all the time with computers, and 
nobody thinks of complaining."
             -- Jef Raskin

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

Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Michael McGrady <mi...@michaelmcgrady.com>]

>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.

I am having a little trouble seeing what you want to do.  Instead of seeing 
how to do what you want to do with ActionForms, it might be helpful to 
first see what you want to do.  Apparently you want to instrument objects 
representing users in sessions.  That should not be doable enough, 
right?  But, I cannot see why you would want to do that with 
ActionForms.  Wouldn't you rather use something like MBeans or a 
roll-your-own similar or related sort of solution?

Michael




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

Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Adam Hardy <ah...@cyberspaceroad.com>]

Have I missed something here? What is wrong with using the reset method 
instead of the constructor? That gives you the mapping and the request 
as parameters.

On 02/03/2004 08:17 AM Michael McGrady wrote:
> I think you really want something other than an ActionForm if you want 
> to do this.  Why anyone would use an ActionForm to do this makes no 
> sense to me.  If you want the request object, then it is in the Action.  
> That is where it should be.
> 
> At 06:59 PM 2/2/2004, Martin Cooper wrote:
> 
>> 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" <je...@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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 


-- 
struts 1.1 + tomcat 5.0.16 + java 1.4.2
Linux 2.4.20 Debian


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

Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Michael McGrady <mi...@michaelmcgrady.com>]

I think you really want something other than an ActionForm if you want to 
do this.  Why anyone would use an ActionForm to do this makes no sense to 
me.  If you want the request object, then it is in the Action.  That is 
where it should be.

At 06:59 PM 2/2/2004, Martin Cooper wrote:
>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" <je...@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



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

Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Martin Cooper <ma...@apache.org>]

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" <je...@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

Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?

[Hubert Rabago <ja...@yahoo.com>]

Not sure how your app is configured, but perhaps you could call an Action to
prepopulate your ActionForm, or help it by passing it the request object.

--- Jeff Skubick <je...@mci.com> wrote:
> 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?


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/

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