You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Leonardo Uribe <lu...@gmail.com> on 2008/06/24 21:45:17 UTC
[VOTE] Upgrade sandbox converters and validators to tomahawk
Hi
The following converters and validators are proposed to be moven from
sandbox to tomahawk core:
s:convertBoolean
s:convertDateTime
s:convertNumber
s:validateCompareTo
s:validateCSV
s:validateISBN
s:validateUrl
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.
Suggestions are welcome!
regards
Leonardo Uribe
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
On Tue, Jun 24, 2008 at 1:52 PM, Leonardo Uribe <lu...@gmail.com> wrote:
>
> On Tue, Jun 24, 2008 at 3:05 PM, Volker Weber <v....@inexso.de> wrote:
>>
>> Hi,
>>
>>
>> converters should go into commons not into tomahawk.
+1
>> Why is this only planed for the 1.2 branch?
>
> That is the hidden reason why I request a vote for this. All validators and
> converters should be on myfaces-commons. Almost all comes from tomahawk or
> sandbox (EnumConverter and DateRestrictValidator available only on commons).
>
> Tomahawk has some validators defined on core:
>
> t:validateCreditCard
> t:validateEmail
> t:validateEqual
> t:validateRegExpr
let's move them over...
>
> This validators right now are defined on myfaces-commons.
>
> One question is if tomahawk core12 should have validators or converters
> defined on its tld(but use the commons jar code), since the plan is that all
> validators and converters should be on myfaces-commons.
why not ?
Just make it a RT dependency, and we are fine.
>
> Other question after answer the first is what should happen on core branch:
> deprecate the actual defined validators and remove it from core12, but where
> should be the sandbox converters and validators? or maybe define it on
> commons jsf11 branch, move all validators and converters from tomahawk and
> release a myfaces-commons-xxxx 1.1.0? .
>
> This is why before I proposed a discussion a vote about myfaces-commons
> layout. There are many alternatives we can do on this topic, but we need to
> be precise about what to do.
>
> The only thing clear is that myfaces commons jsf11 branch should be used
> for backports only.
well, if folks like to add stuff, why not?
>
> The vote proposed is my humble opinion about what to do, but if there are
> better ideas about what to do is the right time to say it.
>
> Suggestions are welcome
seriously, we are adding more and more and more to myfaces...
it get's kinda jakarta like. It's hard to keep track of all the things.
bad signal ?
-Matthias
>
> regards
>
> Leonardo Uribe
>
>>
>> Regards,
>> Volker
>>
>>
>>
>> 2008/6/24 Leonardo Uribe <lu...@gmail.com>:
>> > Hi
>> >
>> > The following converters and validators are proposed to be moven from
>> > sandbox to tomahawk core:
>> >
>> > s:convertBoolean
>> > s:convertDateTime
>> > s:convertNumber
>> > s:validateCompareTo
>> > s:validateCSV
>> > s:validateISBN
>> > s:validateUrl
>> >
>> > 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.
>> >
>> > Suggestions are welcome!
>> >
>> > regards
>> >
>> > Leonardo Uribe
>> >
>> >
>> >
>>
>>
>>
>> --
>> inexso - information exchange solutions GmbH
>> Bismarckstraße 13 | 26122 Oldenburg
>> Tel.: +49 441 4082 356 |
>> FAX: +49 441 4082 355 | www.inexso.de
>
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Leonardo Uribe <lu...@gmail.com>.
On Tue, Jun 24, 2008 at 3:05 PM, Volker Weber <v....@inexso.de> wrote:
> Hi,
>
>
> converters should go into commons not into tomahawk.
> Why is this only planed for the 1.2 branch?
>
That is the hidden reason why I request a vote for this. All validators and
converters should be on myfaces-commons. Almost all comes from tomahawk or
sandbox (EnumConverter and DateRestrictValidator available only on commons).
Tomahawk has some validators defined on core:
t:validateCreditCard
t:validateEmail
t:validateEqual
t:validateRegExpr
This validators right now are defined on myfaces-commons.
One question is if tomahawk core12 should have validators or converters
defined on its tld(but use the commons jar code), since the plan is that all
validators and converters should be on myfaces-commons.
Other question after answer the first is what should happen on core branch:
deprecate the actual defined validators and remove it from core12, but where
should be the sandbox converters and validators? or maybe define it on
commons jsf11 branch, move all validators and converters from tomahawk and
release a myfaces-commons-xxxx 1.1.0? .
This is why before I proposed a discussion a vote about myfaces-commons
layout. There are many alternatives we can do on this topic, but we need to
be precise about what to do.
The only thing clear is that myfaces commons jsf11 branch should be used
for backports only.
The vote proposed is my humble opinion about what to do, but if there are
better ideas about what to do is the right time to say it.
Suggestions are welcome
regards
Leonardo Uribe
>
> Regards,
> Volker
>
>
>
> 2008/6/24 Leonardo Uribe <lu...@gmail.com>:
> > Hi
> >
> > The following converters and validators are proposed to be moven from
> > sandbox to tomahawk core:
> >
> > s:convertBoolean
> > s:convertDateTime
> > s:convertNumber
> > s:validateCompareTo
> > s:validateCSV
> > s:validateISBN
> > s:validateUrl
> >
> > 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.
> >
> > Suggestions are welcome!
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
> >
>
>
>
> --
> inexso - information exchange solutions GmbH
> Bismarckstraße 13 | 26122 Oldenburg
> Tel.: +49 441 4082 356 |
> FAX: +49 441 4082 355 | www.inexso.de
>
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Volker Weber <v....@inexso.de>.
Hi,
converters should go into commons not into tomahawk.
Why is this only planed for the 1.2 branch?
Regards,
Volker
2008/6/24 Leonardo Uribe <lu...@gmail.com>:
> Hi
>
> The following converters and validators are proposed to be moven from
> sandbox to tomahawk core:
>
> s:convertBoolean
> s:convertDateTime
> s:convertNumber
> s:validateCompareTo
> s:validateCSV
> s:validateISBN
> s:validateUrl
>
> 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.
>
> Suggestions are welcome!
>
> regards
>
> Leonardo Uribe
>
>
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Hazem Saleh <ha...@apache.org>.
+1
On Tue, Jun 24, 2008 at 10:45 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> The following converters and validators are proposed to be moven from
> sandbox to tomahawk core:
>
> s:convertBoolean
> s:convertDateTime
> s:convertNumber
> s:validateCompareTo
> s:validateCSV
> s:validateISBN
> s:validateUrl
>
> 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.
>
> Suggestions are welcome!
>
> regards
>
> Leonardo Uribe
>
>
>
--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Leonardo Uribe <lu...@gmail.com>.
+1
On Tue, Jun 24, 2008 at 2:45 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> Hi
>
> The following converters and validators are proposed to be moven from
> sandbox to tomahawk core:
>
> s:convertBoolean
> s:convertDateTime
> s:convertNumber
> s:validateCompareTo
> s:validateCSV
> s:validateISBN
> s:validateUrl
>
> 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.
>
> Suggestions are welcome!
>
> regards
>
> Leonardo Uribe
>
>
>
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Volker Weber <v....@inexso.de>.
Hi,
2008/6/25 simon.kitching@chello.at <si...@chello.at>:
>
> 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).
This means to apply fixes in four places: tomahawk1.1, tomahawk1.2,
commons1.1 and commons1.2.
BTW: -1 for the alternative (tomahawk 1.x, commons).
Regards,
Volker
>
> Regards,
> Simon
>
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Leonardo Uribe <lu...@gmail.com>.
On Wed, Jun 25, 2008 at 4:30 PM, Mike Kienenberger <mk...@gmail.com>
wrote:
> On 6/25/08, simon <si...@chello.at> wrote:
> >
> > On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote:
> > > On 6/25/08, simon.kitching@chello.at <si...@chello.at>
> wrote:
> > > > > s:validateCompareTo
> > > > >
> > > > 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?
> > >
>
Previouly to move s:validateCompareTo, I solved some issues. In this task, I
made some
very simple examples on myfaces-commons-examples and works well.
>
> > > The code was pretty much copied verbatim from the Myfaces JSF core.
> > > In any case, the component has been used by several people for several
> > > years now, and no one has complained. If it's a problem down the
> > > road, I'm sure someone will open a JIRA issue and we can address it at
> > > that time.
> >
> >
> > It occurred to me after looking at the code that an alternative might be
> > to queue an event from the validator. The event should be processed only
> > at the end of the validation phase, at which time all conversion has
> > already been done. That could simplify the converter - and it does feel
> > more elegant to me than having one validator poking around inside
> > another one.
>
> Yes, that idea sounds better. I admit that it's a bit scary that the
> component has to rely on the implementation code from MyFaces. Even
> though it uses public APIs, in practice, it might break on another
> implementation.
>
>
> > > > > 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.
> > > >
> > > > 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).
> > >
> > > I say we mark the tomahawk validator and converter components as
> > > deprecated, leaving them as they are and where they are, and copy
> > > everything to commons.
> > >
> > > No one is forced to upgrade unless they need something fixed or
> > > enhanced, but we don't maintain it in multiple places.
> >
> >
> > I've lost track now. Is there going to be a commons 1.1.x version or
> > not?
> >
> > If there is a commons-1.1.x then I agree my suggestion was completely
> > wrong. These are just sandbox components. So we could move them directly
> > into commons, and not promote them into tomahawk at all.
> >
> > Or possibly leave the original in the sandbox for a while, marked as
> > deprecated so people have some time to migrate. But I'm not sure that is
> > needed for sandbox features.
> >
> > And there would be no dependency from tomahawk to commons. If people
> > want these, they add the commons lib to their path. The commons libs do
> > contain their own tld (with its own namespace), yes?
>
> Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
> approaching the end of its lifecycle.
>
I agree. The idea is going forward with tomahawk 1.2 (or
myfaces-extensions-xxxx), so why waste
time on commons 1.1 (taking into account what the community think about it)
>
> Leave it deprecated in Tomahawk 1.1 (and sandbox). We would want to
> do that anyway for backwards compatibility. Drop it from Tomahawk
> post-1.1 (and sandbox).
>
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by simon <si...@chello.at>.
On Fri, 2008-06-27 at 12:33 -0500, Leonardo Uribe wrote:
>
>
> On Thu, Jun 26, 2008 at 11:54 AM, Mike Kienenberger
> <mk...@gmail.com> wrote:
> On 6/26/08, Volker Weber <v....@inexso.de> wrote:
>
> > > Does it really matter if there's a commons 1.1?
> Tomahawk 1.1 is fast
> > > approaching the end of its lifecycle.
> >
> >
> > Yes, it does. At least to me.
> >
> > Commons1.1 is not a tomahawk1.1 extension, it should
> contain things
> > for jsf1.1 application developpers.
> > As long as there is active development in jsf1.1
> applications, there
> > is a need for a commons1.1 version.
> >
> > We are just going in production with a tobago/jsf1.1
> application,
> > developed within the last three years,
> > and i can't see the time to switch to jsf1.2 in the next
> months while
> > we need to add extensions for specific customers.
>
>
> Volker,
>
> I'm not saying we shouldn't have a commons 1.1. I think we
> should.
> What I'm saying is that even if we do not have a commons 1.1,
> we
> should stop maintaining the validators and converters as part
> of
> Tomahawk. If someone thinks they are worth supporting in
> 1.1, they
> should so as part of commons 1.1.
>
> We need a conclusion about this topic.
>
> One of the options presented is:
>
> 1. Deprecate converters and validators for tomahawk 1.1 (and let all
> converters and validators where are, just note it).
> 2. Move tomahawk converters and validators to myfaces-commons (1.2
> done, 1.1 branch in progress).
>
> Does the community agree with that proposal?
+1
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Leonardo Uribe <lu...@gmail.com>.
On Thu, Jun 26, 2008 at 11:54 AM, Mike Kienenberger <mk...@gmail.com>
wrote:
> On 6/26/08, Volker Weber <v....@inexso.de> wrote:
>
> > > Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
> > > approaching the end of its lifecycle.
> >
> >
> > Yes, it does. At least to me.
> >
> > Commons1.1 is not a tomahawk1.1 extension, it should contain things
> > for jsf1.1 application developpers.
> > As long as there is active development in jsf1.1 applications, there
> > is a need for a commons1.1 version.
> >
> > We are just going in production with a tobago/jsf1.1 application,
> > developed within the last three years,
> > and i can't see the time to switch to jsf1.2 in the next months while
> > we need to add extensions for specific customers.
>
> Volker,
>
> I'm not saying we shouldn't have a commons 1.1. I think we should.
> What I'm saying is that even if we do not have a commons 1.1, we
> should stop maintaining the validators and converters as part of
> Tomahawk. If someone thinks they are worth supporting in 1.1, they
> should so as part of commons 1.1.
>
We need a conclusion about this topic.
One of the options presented is:
1. Deprecate converters and validators for tomahawk 1.1 (and let all
converters and validators where are, just note it).
2. Move tomahawk converters and validators to myfaces-commons (1.2 done, 1.1
branch in progress).
Does the community agree with that proposal?
regards
Leonardo Uribe
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 6/26/08, Volker Weber <v....@inexso.de> wrote:
> > Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
> > approaching the end of its lifecycle.
>
>
> Yes, it does. At least to me.
>
> Commons1.1 is not a tomahawk1.1 extension, it should contain things
> for jsf1.1 application developpers.
> As long as there is active development in jsf1.1 applications, there
> is a need for a commons1.1 version.
>
> We are just going in production with a tobago/jsf1.1 application,
> developed within the last three years,
> and i can't see the time to switch to jsf1.2 in the next months while
> we need to add extensions for specific customers.
Volker,
I'm not saying we shouldn't have a commons 1.1. I think we should.
What I'm saying is that even if we do not have a commons 1.1, we
should stop maintaining the validators and converters as part of
Tomahawk. If someone thinks they are worth supporting in 1.1, they
should so as part of commons 1.1.
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Volker Weber <v....@inexso.de>.
Hi,
2008/6/25 Mike Kienenberger <mk...@gmail.com>:
> On 6/25/08, simon <si...@chello.at> wrote:
>>
>> On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote:
>> > On 6/25/08, simon.kitching@chello.at <si...@chello.at> wrote:
>> > > > s:validateCompareTo
>> > > >
>> > > 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?
>> >
>> > The code was pretty much copied verbatim from the Myfaces JSF core.
>> > In any case, the component has been used by several people for several
>> > years now, and no one has complained. If it's a problem down the
>> > road, I'm sure someone will open a JIRA issue and we can address it at
>> > that time.
>>
>>
>> It occurred to me after looking at the code that an alternative might be
>> to queue an event from the validator. The event should be processed only
>> at the end of the validation phase, at which time all conversion has
>> already been done. That could simplify the converter - and it does feel
>> more elegant to me than having one validator poking around inside
>> another one.
>
> Yes, that idea sounds better. I admit that it's a bit scary that the
> component has to rely on the implementation code from MyFaces. Even
> though it uses public APIs, in practice, it might break on another
> implementation.
>
>
>> > > > 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.
>> > >
>> > > 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).
>> >
>> > I say we mark the tomahawk validator and converter components as
>> > deprecated, leaving them as they are and where they are, and copy
>> > everything to commons.
>> >
>> > No one is forced to upgrade unless they need something fixed or
>> > enhanced, but we don't maintain it in multiple places.
>>
>>
>> I've lost track now. Is there going to be a commons 1.1.x version or
>> not?
>>
>> If there is a commons-1.1.x then I agree my suggestion was completely
>> wrong. These are just sandbox components. So we could move them directly
>> into commons, and not promote them into tomahawk at all.
>>
>> Or possibly leave the original in the sandbox for a while, marked as
>> deprecated so people have some time to migrate. But I'm not sure that is
>> needed for sandbox features.
>>
>> And there would be no dependency from tomahawk to commons. If people
>> want these, they add the commons lib to their path. The commons libs do
>> contain their own tld (with its own namespace), yes?
>
> Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
> approaching the end of its lifecycle.
Yes, it does. At least to me.
Commons1.1 is not a tomahawk1.1 extension, it should contain things
for jsf1.1 application developpers.
As long as there is active development in jsf1.1 applications, there
is a need for a commons1.1 version.
We are just going in production with a tobago/jsf1.1 application,
developed within the last three years,
and i can't see the time to switch to jsf1.2 in the next months while
we need to add extensions for specific customers.
Regards,
Volker
>
> Leave it deprecated in Tomahawk 1.1 (and sandbox). We would want to
> do that anyway for backwards compatibility. Drop it from Tomahawk
> post-1.1 (and sandbox).
>
--
inexso - information exchange solutions GmbH
Bismarckstraße 13 | 26122 Oldenburg
Tel.: +49 441 4082 356 |
FAX: +49 441 4082 355 | www.inexso.de
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 6/25/08, simon <si...@chello.at> wrote:
>
> On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote:
> > On 6/25/08, simon.kitching@chello.at <si...@chello.at> wrote:
> > > > s:validateCompareTo
> > > >
> > > 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?
> >
> > The code was pretty much copied verbatim from the Myfaces JSF core.
> > In any case, the component has been used by several people for several
> > years now, and no one has complained. If it's a problem down the
> > road, I'm sure someone will open a JIRA issue and we can address it at
> > that time.
>
>
> It occurred to me after looking at the code that an alternative might be
> to queue an event from the validator. The event should be processed only
> at the end of the validation phase, at which time all conversion has
> already been done. That could simplify the converter - and it does feel
> more elegant to me than having one validator poking around inside
> another one.
Yes, that idea sounds better. I admit that it's a bit scary that the
component has to rely on the implementation code from MyFaces. Even
though it uses public APIs, in practice, it might break on another
implementation.
> > > > 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.
> > >
> > > 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).
> >
> > I say we mark the tomahawk validator and converter components as
> > deprecated, leaving them as they are and where they are, and copy
> > everything to commons.
> >
> > No one is forced to upgrade unless they need something fixed or
> > enhanced, but we don't maintain it in multiple places.
>
>
> I've lost track now. Is there going to be a commons 1.1.x version or
> not?
>
> If there is a commons-1.1.x then I agree my suggestion was completely
> wrong. These are just sandbox components. So we could move them directly
> into commons, and not promote them into tomahawk at all.
>
> Or possibly leave the original in the sandbox for a while, marked as
> deprecated so people have some time to migrate. But I'm not sure that is
> needed for sandbox features.
>
> And there would be no dependency from tomahawk to commons. If people
> want these, they add the commons lib to their path. The commons libs do
> contain their own tld (with its own namespace), yes?
Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
approaching the end of its lifecycle.
Leave it deprecated in Tomahawk 1.1 (and sandbox). We would want to
do that anyway for backwards compatibility. Drop it from Tomahawk
post-1.1 (and sandbox).
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by simon <si...@chello.at>.
On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote:
> On 6/25/08, simon.kitching@chello.at <si...@chello.at> wrote:
> > > s:validateCompareTo
> > >
> > 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?
>
> The code was pretty much copied verbatim from the Myfaces JSF core.
> In any case, the component has been used by several people for several
> years now, and no one has complained. If it's a problem down the
> road, I'm sure someone will open a JIRA issue and we can address it at
> that time.
It occurred to me after looking at the code that an alternative might be
to queue an event from the validator. The event should be processed only
at the end of the validation phase, at which time all conversion has
already been done. That could simplify the converter - and it does feel
more elegant to me than having one validator poking around inside
another one.
>
>
> > > 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.
> >
> > 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).
>
> I say we mark the tomahawk validator and converter components as
> deprecated, leaving them as they are and where they are, and copy
> everything to commons.
>
> No one is forced to upgrade unless they need something fixed or
> enhanced, but we don't maintain it in multiple places.
I've lost track now. Is there going to be a commons 1.1.x version or
not?
If there is a commons-1.1.x then I agree my suggestion was completely
wrong. These are just sandbox components. So we could move them directly
into commons, and not promote them into tomahawk at all.
Or possibly leave the original in the sandbox for a while, marked as
deprecated so people have some time to migrate. But I'm not sure that is
needed for sandbox features.
And there would be no dependency from tomahawk to commons. If people
want these, they add the commons lib to their path. The commons libs do
contain their own tld (with its own namespace), yes?
Regards,
Simon
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 6/25/08, simon.kitching@chello.at <si...@chello.at> wrote:
> > s:validateCompareTo
> >
> 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?
The code was pretty much copied verbatim from the Myfaces JSF core.
In any case, the component has been used by several people for several
years now, and no one has complained. If it's a problem down the
road, I'm sure someone will open a JIRA issue and we can address it at
that time.
> > 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.
>
> 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).
I say we mark the tomahawk validator and converter components as
deprecated, leaving them as they are and where they are, and copy
everything to commons.
No one is forced to upgrade unless they need something fixed or
enhanced, but we don't maintain it in multiple places.
Re: [VOTE] Upgrade sandbox converters and validators to tomahawk
Posted by "simon.kitching@chello.at" <si...@chello.at>.
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