Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?
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 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?
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 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Why doesn't ActionForm's constructor have access to HttpServletRequest?
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?
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?
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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why doesn't ActionForm's constructor have access to HttpServletRequest?
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 [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
