----- Original Message ----- From: "Mainguy, Mike" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 1:44 PM Subject: RE: [repost] Special view information -> ActionForm or request?
> As far as the forms are concerned, I whole-heartedly agree that the current > notion of populating the form "one the way" to getting mapped to the view > seems pretty clumsy. I would almost advocate having the forms to be > "pulled" (as above) out of some persistant service thingy (highly technical > term). Of course, it would then require that we have some sort of populate > or load method that will do something before we process anything. It seems > also like a variation of how the dispatchaction works would be kinda cool. > Allowing, either based on URL or some other request info, you to determine > if you are doing a read or a write "before" you even get to the action would > be the better way to go. This discussion is getting me to thinking that in addition to the notion of an ActionForm we need a parallel formalized java bean that is in charge of non-form information that a view needs. Perhaps this object could be called an ActionView. This could be documented with types in the struts-config file and would provide not only a convenient API for JSP developers but would also improve the documentation of how data gets transferred from the Java to JSP layer. I can't decide if the ActionView should be populated before the execution of an Action, after the execution of an Action, or during the execution of an Action. I guess the most flexible would be for it to be populated during the execution of the Action. The ActionView could be saved to the request or session with a saveActionView() method. To configure the behavior of the saveActionView() method the <action> element in struts-config could be extended with viewBeanName and viewBeanScope attributes which would mirror the name and scope attributes for ActionForms. Another random thought is that ActionView should probably be an interface so an existing JavaBean can be used if desired. If an existing JavaBean does not exist, one could be configured similarly to DynaActionForms in struts config in a <view-beans> section that had syntax nearly identical to that of <form-beans>. > Of course, that's just my perspective, but, your notion of the clumsiness of > stuffing data into the form in the Action (especially after the request data > has already been stuffed in there once) struck a chord with me. 100% agree. ActionForm feels like it is doing double-duty if you stuff things like java.util.List into it. ActionForm should really only have boolean and String values since these are the only values that can be automatically pulled from the request parameters. > Evidently the development in struts is a little more active than I thought, > I may have to start pulling down snapshots... > > -----Original Message----- > From: Joe Germuska [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 18, 2003 1:29 PM > To: Struts Users Mailing List > Subject: RE: [repost] Special view information -> ActionForm or request? > > > I don't have a very strong opinion, but for form *choices*, I've > always preferred to put them into some page-accessible context before > dispatching to a page. > > I wrote a class called DigestingPlugIn which was added to Struts > after the 1.1 release which is designed to make it easy to put a menu > like this into the application context so that it's always available > to all your pages, even if they don't go through an action before > display. Of course, if the choices are dynamic and specific to the > request or the session, this doesn't work, but for things like > sharing a menu of states or countries, it works pretty well. If you > aren't comfortable using unreleased Struts code, you can get a > library version of this class from http://demo.jgsullivan.com/struts/ > > Another alternative for request/session-specific options would be to > extend the OptionsCollection tag to be smarter about how it gets the > collection for iteration -- this would allow you to route people > directly to the JSP without needing to go through an action class. > > We've been having a vigorous discussion over the last couple of days > about the best way to prefill form *values* in a pre-validation > context, and to be honest, I feel like this is a use case which > Struts doesn't address very well. It feels clumsy to fool around > with creating an ActionForm and populating it "on the way" to the > view; should I just get over that? Or is this something about Struts > that deserves a closer look with an eye towards addressing the use > case more directly? I've been meaning to search the archives to see > what discussions have come up, but since I'm sending this message, I > guess I'll just dump it out there and see what people think... > > Joe > > > > > At 12:35 -0400 9/18/03, Mainguy, Mike wrote: > >I also would like other's opinion on this. Right now, use a service > >locator style class to stuff all my lookup stuff into the request > >object manually. I have, however, used collections in the formbeans for > >this. I can't, off the top of my head, think of any significant > >advantages to using a form bean. One disadvantage, however, is you can > >only have 1 form bean per action, so lookups across multiple actions > >will need to have duplicate code. > > > > > >-----Original Message----- > >From: Sgarlata Matt [mailto:[EMAIL PROTECTED] > >Sent: Thursday, September 18, 2003 10:15 AM > >To: Struts Users Mailing List > >Subject: [repost] Special view information -> ActionForm or request? > > > > > >Sorry for the repost. Has this already been discussed? I couldn't > >find it in the archives. > > > >Original message: > > > >Sometimes views need special information to display correctly, like a > >bean with the values needed to render a dropdown list. Is it > >considered a Struts best-practice to include this information in the > >ActionForm or should the Action which prepares this information store > >the information in the request instead? > > > >Thanks, > > > >Matt > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >This message and its contents (to include attachments) are the > >property of Kmart Corporation (Kmart) and may contain confidential > >and proprietary information. You are hereby notified that any > >disclosure, copying, or distribution of this message, or the taking > >of any action based on information contained herein is strictly > >prohibited. Unauthorized use of information contained herein may > >subject you to civil and criminal prosecution and penalties. If you > >are not the intended recipient, you should delete this message > >immediately. > > > > > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > -- > -- > Joe Germuska > [EMAIL PROTECTED] > http://blog.germuska.com > "If nature worked that way, the universe would crash all the time." > --Jaron Lanier > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. > > > > --------------------------------------------------------------------- > 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]
