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.
Suggestions are welcome
o What is the impact on the other components, i.e. Trinidad/Tobago/...?
o Is this to be included in Tomahawk 1.1.7?
o How long do you expect this to take, i.e. days/weeks/months/... ?
(I am only asking to set expectation on release schedules)
o Where is the "new unpack plugin" documented?
regards
Leonardo Uribe
Paul Spencer
