On Fri, Jun 6, 2008 at 1:06 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I'd recommend not migrating t:validateEqual across to myfaces-commons. > t:validateEquals is a special case of t:validateCompareTo, and, if I > recall correctly, the code in validateEquals is not as flexible as the > code in validateCompareTo. There's no point in maintaining the > inferior limited version in the reorganization.
+1 > > On 6/6/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote: >> >> >> >> On Fri, Jun 6, 2008 at 8:54 AM, Paul Spencer <[EMAIL PROTECTED]> wrote: >> > Leonardo Uribe wrote: >> > >> > > >> > > Hi >> > > >> > > I'll start to upgrade component from sandbox to tomahawk. >> > > >> > > The first item on my list of todos is move this converters and >> validators >> > > (first check and solve possible issues on JIRA) >> > > >> > > s:convertBoolean >> > > s:convertDateTime >> > > s:convertNumber >> > > s:validateCompareTo >> > > s:validateCSV >> > > s:validateISBN >> > > s:validateUrl >> > > >> > > Please note that long time ago this upgrade was approved, but this was >> not >> > > applied due to code generation discussion. >> > > >> <file:///C:/GSOC/workspace/tomahawk-compgen/oldsandbox-site/tlddoc/s/validateUrl.html> >> > > >> > > >> > > Actually on tomahawk exists this validators: >> > > >> > > t:validateCreditCard >> > > t:validateEmail >> > > t:validateEqual >> > > t:validateRegExpr >> > > >> > > The idea is that all this converters and validators be on >> myfaces-commons. >> > > But originally tomahawk is 1.1 compatible, and there was comments about >> > > commons should have 1.1 and 1.2 converters and validators. If this is >> true, >> > > tomahawk should refer myfaces commons converters and validators on its >> tld, >> > > and have dependecies to commons (if false this is valid only for 1.2). >> > > >> > > >> > >> > +1 for true. The thought of maintaining 2 sets of converts/valdiators is >> unnerving. >> > >> > >> > >> > > The new unpack plugin allow us to manage this issues more easily, >> enforcing >> > > just the necessary files to maintain. >> > > >> > > In order to be consistent with this intentions my first approach would >> be: >> > > >> > > 1. Use this layout for myfaces-commons: >> > > >> > > myfaces-commons-converters >> > > myfaces-commons-converters12 >> > > myfaces-commons-validators >> > > myfaces-commons-validators12 >> > > myfaces-commons-utils >> > > >> > > 2. Use myfaces-builder-plugin for this stuff. >> > > >> > > 3. Refer converters and validator from commons to tomahawk tld (the >> > > intention is avoid changes on existing applications). >> > > >> > > >> > I suggest deprecating the existing converters/validators. >> > >> >> Good idea but needs some concensus about this. Deprecate means do not >> exclude it but refer the users to myfaces commons. >> >> > >> > >> > > Suggestions are welcome >> > > >> > > >> > >> > o What is the impact on the other components, i.e. Trinidad/Tobago/...? >> > >> >> no impact, myfaces commons does not have any release yet and does not have >> dependencies with anything (the idea of this discussion is organize this >> stuff and make a release of this!). >> >> > >> > o Is this to be included in Tomahawk 1.1.7? >> > >> >> yes >> > >> > o How long do you expect this to take, i.e. days/weeks/months/... ? >> > (I am only asking to set expectation on release schedules) >> > >> >> days, at max weeks >> >> > >> > o Where is the "new unpack plugin" documented? >> > >> >> http://myfaces.apache.org/build-tools/plugins/myfaces-builder-plugin/unpack-mojo.html >> >> There is more doc on the source code (the site has not been updated, but >> this doc is fine). This is a work in progress. >> >> >> > >> > >> > > regards >> > > >> > > Leonardo Uribe >> > > >> > > >> > >> > >> > Paul Spencer >> > >> >> > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
