myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "simon.kitching@chello.at" <simon.kitch...@chello.at>
Subject Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Date Wed, 25 Jun 2008 08:46:53 GMT
Leonardo Uribe schrieb:
> Hi
>
> The following converters and validators are proposed to be moven from 
> sandbox to tomahawk core:
>
> s:convertBoolean
+1
> s:convertDateTime
Only if the comment on this class is updated. It should read something like:

 Interprets dates as being in the local timezone of the server.
 This converter is therefore useful only for dinky little websites where 
every
 single user is in the same timezone. For real websites, use the standard
 h:convertDateTime.
> s:convertNumber
We've had problems with the convertNumber converter here recently. I 
think its TLD API needs careful review before it is promoted.
> s:validateCompareTo
The javadoc needs to be cleaned up at least. There is plenty of good 
info there, but it is not in valid javadoc format.

And all that code about independently converting a component's submitted 
value makes me a little nervous. It looks ok, but has anyone properly 
reviewed it?

> s:validateCSV
> s:validateISBN
> s:validateUrl
+1

>
> In tomahawk core, the related files should be moved from sandbox/core 
> to core. In tomahawk core12, a new  dependency to 
> myfaces-commons-converters 1.2.x and myfaces-commons-validators 1.2.x 
> should be added, so the tomahawk core12 tld reference validators and 
> converters from these projects. This introduce a change because
> the validatorId and converterId for this components changes (because 
> this converters are defined on myfaces-commons) only on core12.
>
> If you want to see this change on tomahawk please vote.
>
> This was discussed positively before, but the times change and better 
> to know what people think about it.

I don't like the idea of tomahawk1.x having these components internally, 
while tomahawk2.x uses the version from commons. It's ugly and confusing.

While code duplication is never nice, I think it would be better for 
tomahawk 1.1.x and 1.2.x to continue to have these components 
internally, and for commons to have a separate version. It also means 
that commons can clean up the API without breaking tomahawk users. Yes, 
it does mean having to apply fixes in two places (tomahawk, commons) but 
so does the alternative (tomahawk 1.x, commons).

Regards,
Simon


Mime
View raw message