My first suggestion would be try not to think in terms of request parameters and try to think in terms of ActionForm properties. Generally, all the request parameters should be represented as ActionForm properties. Struts will then take care of automatically populating the properties.
My second suggestion would be to try and put gory details like id= 104 behind ActionForward. Instead creating an ActionForward by appending the parameter, you can call the forward by name. I don't know what 104 does, but you could have the equivalent of <forward name="home104" path:/home.do?id=104"/> Where home104 is a descriptive name rather than an arbitrary identifier. My third suggestion would be to use an ActionMapping for the input property rather than a presentation page. Ideally, all pages should be behind ActionMapping handlers. If you need to apply some post-validation logic or seed any properties (!parameters) on the ActionForm, you can do that here. -Ted. 12/17/2002 1:10:28 PM, Brian Moseley <[EMAIL PROTECTED]> wrote: > >any comments on the problem i've outlined below? > >i realize that it's not clean to give a form bean any amount of control >logic (which is what i want to do by allowing it to manipulate the input >path). i'd prefer to avoid this if possible. > >one thought is that RequestProcessor.process could offer a "post >validation" hook that would allow the input path to be specified by an >application component. but which component? neither actions or forms >make sense here. > >another thought: form definitions in struts-config optionally specify >sprintf-like format strings which are used by the >mapping/forward/whatever to dynamically generate paths. > >once again, the requirement i have to live with is that my form's input >page requires a particular request parameter to be set. it's just a form >for modifying the attributes of a model object, and the request >parameter is simply the object's unique id. > >this is clearly a common design pattern; how do other people solve the >problem of providing a needed request parameter to an action form's >input after a failed validation? > >Brian Moseley wrote: >> >> i sent the below message to struts-user a couple of days ago. since that >> time i tried to address the problem by creating a subclass of >> RequestProcessor and overriding the process method. didn't work. >> >> i figured i could make an "unfrozen clone" of the mapping to pass into >> processValidate, which would allow my form to set the input path inside >> its validate method. unfortunately, there was no clean way to do this; i >> didn't want to cut and paste processValidate into my subclass, and there >> is no hook within process to allow a subclass to step in and create the >> mapping clone. >> >> i wound up having the form set a session attribute which the action then >> gets and removes. a grotesque solution to be sure, but the only apparent >> alternative was worse. >> >> so the question i put to you folks is: how must struts change to allow >> me to modify the mapping's input path inside the form's validate method? >> or is there some existing solution that i'm completely missing? >> >> thanks! >> >> Brian Moseley wrote: >> >>> i'm using struts 1.1b2 to perform a simple validation on an action >>> form. it works great, except: >>> >>> when validation fails, i need to specify an additional request >>> parameter for the input path, as the input page requires that >>> parameter to exist. unfortunately, i get a "configuration frozen" >>> error when i try to modify the input path in the action form's >>> validate method. >>> >>> i've considered but rejected using a session attribute instead of a >>> request parameter for this particular piece of data. other than that, >>> is there a solution that i'm missing? >>> >>> thanks! >>> >> >> >> > > > > >-- >To unsubscribe, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:struts-dev- [EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
