+1 for adding examples. On Tue, Jun 17, 2008 at 1:12 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> Leo, > I will start adding the base exporterListener to commons after your > refactoring. > Thanks. > > > On Tue, Jun 17, 2008 at 1:56 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote: > >> Hi >> >> I'll start to refactor myfaces-commons to the new proposed layout (I'm not >> started this yet because it was necessary check the actual state of >> converters and validators and solve some related issues): >> >> myfaces-commons-converters >> myfaces-commons-converters12 >> myfaces-commons-validators >> myfaces-commons-validators12 >> myfaces-commons-utils >> >> It could be good if we have also a: >> >> myfaces-commons-examples >> >> As a simple web app with all examples related to myfaces commons stuff >> (converters and validators). I is obvious to have this project, so I don't >> think this require a vote. >> >> The list of components that should be moved to this location are this: >> >> mcc:convertBoolean >> mcc:convertDateTime >> mcc:convertNumber >> mcv:validateCompareTo >> mcv:validateCSV >> mcv:validateISBN >> mcv:validateUrl >> mcv:validateCreditCard >> mcv:validateEmail >> mcv:validateRegExpr >> >> validateEqual should be deprecated because validateCompareTo it is better >> (according to the suggestion of Mike), so this validator should stay on >> tomahawk. The rest of converters and validators only be referenced by >> tomahawk tld (so myfaces-commons becomes a tomahawk dependency). >> >> Suggestions are welcome >> >> regards >> >> Leonardo Uribe >> >> On Fri, Jun 13, 2008 at 9:24 PM, Matthias Wessendorf <[EMAIL PROTECTED]> >> wrote: >> >>> 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 >>> >> >> > > > -- > Hazem Ahmed Saleh Ahmed > http://www.jroller.com/page/HazemBlog -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
