Actually, now that you mention it, there are prefix and suffix properties to the ActionMapping, which might help you with this. If you specify a prefix and/or suffix in the ActionMapping for the form, the population routines prepend or append these when matching the request parameters to the form properties.
What this does is make the propery aaaThis equivalent to This -- either will map to setThis(). Without making any changes, you could create form properties as such: <input type='text' name='aaaThis' value='<bean:write name="thisForm" property="this">'> where aaa is the prefix you want to use, and the Struts config ActionMapping it is submitting to includes the property prefix="aaa" Though, getting the html tags to use the same prefix/suffix specified in the ActionMapping seems like a valid idea to me. So the tags would check the mapping (in the request) for a prefix or suffix, and then apply it to the control name when it is written out. This would allow you to make the change without editing Java or JSP code, but just by updating the Struts config. Of course, this would break any JavaScript references to a control when a prefix was added or changed, since the apparent name of the control would also change. Laurie Harper wrote: > > Yes, this became clearer when I tracked down the code that actually > popluates the form bean. The problem would be knowing which properties > to populate with which parameters. The request would have to carry > additional mapping data, which would certainly be less than clean. > > I think I can achieve what I want, though, by using a prefix or suffix > for the parameter names and passing that into the bean during form > generation. Then the population process can simply retrieve the prefix > from the bean and use that to select the set of parameters. > > Does that sound workable? > > L. > > On Wed, 2001-11-14 at 17:34, Ted Husted wrote: > > I'm not sure how this would work. > > > > The request parameters are meant to match the properties on an > > ActionForm bean. If they do not match the ActionForm properties, then > > ActionForm will not be populated by the ActionServlet, and the purpose > > of the HTML tags is defeated. This is all done by reflection, so the > > property names do matter, and cannot be changed on the fly. > > > > If I understand your requirements, Struts would not be a good choice, > > since the way Actions are specified in the html:form tag makes them > > difficult to use as pluggable components. > > > > > > > > Laurie Harper wrote: > > > > > > Another question on the STRUTS HTML taglib. One of the design > > > guidelines on the project I'm working on is that it should be possible > > > to alter the request parameters a JSP page uses by editting the JSP file > > > (i.e. without makeing code changes). The reasoning is to allow re-use > > > of components (forms, etc) on multiple pages without code modification. > > > If request parameters are defined by code, as they are with the STRUTS > > > HTML tags, request parameter naming collisions can occur when trying to > > > combine components in new ways. > > > > > > The way we achieve this generally is to pass request parameter names > > > into custom tags via attributes and have the tags retrieve the data they > > > need from the named parameter. That allows us to have type-safe Java > > > code wrapping request parameter access (i.e. the tag calls a typed > > > getter which retrieves the named request parameter and validates it > > > before returning it). > > > > > > So, my question: would there be any interest in extensions to the STRUTS > > > HTML tag libs to support this decoupling? It'd be something along the > > > lines of an additional attribute to complement the 'property' attribute, > > > say 'param'. If supplied, the value of the 'param' attribute would be > > > used for the request parameter name when submitting the form. The > > > parameter would get mapped to the bean property named by 'property'. > > > > > > Does this make sense? Does it make more sense as an extension to the > > > STRUTS bean taglib? (I haven't looked at the bean taglib at all, so I'm > > > not sure.) > > > > > > If it doesn't make sense as part of STRUTS, I'll implement it as a local > > > extension. If it does, I'll be happy to contribute the extension as a > > > patch for possible inclusion in STRUTS. > > > > > > Thanks, > > > > > > L. > > > -- > > > zodiac(@)holoweb!net | "If that's too much initiative for the company > > > to > > > ICQ# 78724820 | handle, I don't want to work for them anyway." > > > > > > -- > > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- > zodiac(@)holoweb!net | "If that's too much initiative for the company > to > ICQ# 78724820 | handle, I don't want to work for them anyway." > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
