I'll ask the dumb question What is Strike-thru formatting? ~Martin~ ----- Original Message ----- From: "Joe Germuska" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Sunday, March 07, 2004 6:12 PM Subject: Re: Struts starter
> At 9:14 PM +0000 3/7/04, Frank Burns wrote: > >Hi, > >I'm in the middle of working with my first application using Struts > >and desperately need some help. > >I've read nearly all of Ted Husted's "Struts In Action" book and > >browsed the mailing list archives but have not found a solution for > >what I want to do. > >I mention this to let you know that I have already tried hard, > >unsuccessfully, to find an answer to what seems to me to be a basic > >requirement. > >However, I may be struggling with my own misunderstanding! > > Frank: > > Don't blame yourself: you've stumbled onto one of my personal top > priorities to improve in Struts: prefilling forms with non-request > data. > > While I was writing this, John McGrath described a general strategy > which works *if* you don't already need to use the single > "ActionForm" that is passed to Action.execute for processing *input* > data. However, in most cases, you have a chain of events where you > have different "input" and "output" forms. We've developed a few > strategies for ealing with this where I work, but they're all the > sort of thing which may not be ready for "prime time" -- that is, > officially adding to the Struts core. > > Right now, Struts doesn't provide a particularly convenient way to > get an instance of what we call the "output" form -- the form which > will be in the view to which control is directed. Since 1.2.0, I've > committed a few changes which make it a little easier for you to get > Form Bean instances, but what is still missing right now is a > proposal for a standard place to configure Struts to know which form > bean you want. > > Practically speaking, you can get an Object of the right class from a > static method of RequestUtils with no more than a FormBeanConfig and > the ActionServlet. You can get a FormBeanConfig from a ModuleConfig > instance, which you can get using ModuleUtils. So inside any Action, > you can bootstrap yourself to having a Form bean object, which you > can populate however you need. > > http://jakarta.apache.org/struts/api/org/apache/struts/util/RequestUtils.htm l#createActionForm(org.apache.struts.config.FormBeanConfig,%20org.apache.str uts.action.ActionServlet) > > http://jakarta.apache.org/struts/api/org/apache/struts/config/ModuleConfig.h tml#findFormBeanConfig(java.lang.String) > > http://jakarta.apache.org/struts/api/org/apache/struts/util/ModuleUtils.html #getModuleConfig(javax.servlet.http.HttpServletRequest) > > One possible flaw with this (as it is now) is that it doesn't honor > the "scope" parameter and search the request or session for possibly > existing bean instances. Of course, that code is available inside > non-public methods of RequestUtils; it's just a matter of choosing > the right way of exposing them publicly. > > The sticky parts, in terms of packing this up so that it's easy for > everyone to use in Struts is configuring the form bean name and scope > in the right place -- where in the struts-config.xml (or in some > other file) would you tell Struts the name (and scope) of the bean > you want? > > At work, we're using the struts-chain "ComposableRequestProcessor" > with a request chain command "PagePrep", which looks up config > information and choreographs finding a form bean and making it > available to a piece of Java code which might know how to populate > it. But Struts is still a good bit away from officially switching to > the ComposableRequestProcessor, and our config information is part of > a general "UIToolkit" which is not currently a part of Struts in any > way. > > The general strategy we use would fit decently well into a Tiles > "Controller," except that a Tiles Controller doesn't have access to > the running Servlet, and if you use ValidatorForms, your FormBean > must have access to the Servlet object. There's been some talk about > trying to apply the general "controller" pattern to all Struts > forwards, and in some ways, that's what we do with our "PagePrep" > strategy, but it's been a while since anyone suggested a specific > approach, and I don't think I've ever seen any actual code to do it. > > I'd be open to community discussions about how to integrate some > behavior like this into Struts before we get there, but I must admit > that since I have a solution where I need it, I'll need some external > motivation to work on a solution that fits into the current > RequestProcessing model. > > This was discussed at great length last Spring (that long ago?!) > > http://marc.theaimsgroup.com/?l=struts-dev&m=105415755227385&w=2 > > but nothing ever congealed the point where code was cut for the core > Struts distribution. > > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
