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. > > -- Ted Husted, Husted dot Com, Fairport NY USA. > -- Custom Software ~ Technical Services. > -- Tel +1 716 737-3463 > -- http://www.husted.com/struts/ > > > 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]>
