On Sat, 7 Jul 2001, Ted Husted wrote:
> David Winterfeldt wrote:
> > I don't know. I could go either way. I think it
> > makes sense having the ValidatorForm in
> > org.apache.struts.action.
>
> +1 on org.apache.struts.action if that's what you want to do.
>
> > Are there any issues with breaking backwards
> > compatibility? I'm for replacing the validator
> > version for the current since iterating throught the
> > errors further encourages formatting to be in the
> > view. If we do replace the old tag, would it still be
> > somewhere for people to access the old tag that
> > migrate from Struts 1.0 to Struts 1.1? Possibly
> > called html:errorsOld or old-html:errors. Or the new
> > one could be html:errorsIterator.
>
> Craig setup a 1.1 DTD so we could make changes there without affecting
> the 1.0 users. I guess we need a similar strategy for the taglibs
> themselves. If we made the old taglib available as struts-html-10, then
> they could keep compatible just by changing the web.xml reference, or
> something.
>
Setting up a different taglib (struts-html-10) still forces old users to
change every page when they migrate to 1.1 :-(.
If its feasible, I'd like us to stick with a policy like this for tags:
* You can add new optional attributes to an existing tag,
as long as the default behavior remains as it was before.
* If you are creating a substantially improved version of an
old tag, deprecate the old one and create the new tag with
a new name (or the same name in a new taglib).
Following this philosophy, we'd create a new tag (perhaps
<html:messages>?) for the new functionality, and deprecate
<html:errors>. In addition, we'd need to change the 1.1 implementation of
<html:errors> so that it did something sensible, even in the face of a
"new and improved" error messages object.
What do you think?
> -Ted.
>
Craig
