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