Return-Path: Delivered-To: apmail-jakarta-struts-dev-archive@jakarta.apache.org Received: (qmail 95480 invoked by uid 500); 7 Jul 2001 21:10:49 -0000 Mailing-List: contact struts-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk Reply-To: struts-dev@jakarta.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list struts-dev@jakarta.apache.org Received: (qmail 95468 invoked by uid 1059); 7 Jul 2001 21:10:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 7 Jul 2001 21:10:49 -0000 Date: Sat, 7 Jul 2001 14:10:49 -0700 (PDT) From: "Craig R. McClanahan" X-Sender: craigmcc@localhost To: struts-dev@jakarta.apache.org Subject: Re: /contrib In-Reply-To: <3B4773E0.FEA9560@apache.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N 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 ?) for the new functionality, and deprecate . In addition, we'd need to change the 1.1 implementation of so that it did something sensible, even in the face of a "new and improved" error messages object. What do you think? > -Ted. > Craig