You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2014/02/26 11:23:13 UTC
Wicket 7: IChoiceRenderer restore or keep out?
While upgrading our application the biggest time sink for now was going
through our code base and fixing the issues that came from removing
IChoiceRenderer. While I don't mind the work (mostly search and replace) I
would like to learn about the reasoning for removing the interface.
In my previous trial Sven noticed that he'd like to see IChoiceRenderer
restored. I'd like to start the discussion and resolve it before we cut a
7-M1 release-to prevent having to go through the motions of re-introducing
the interface after folks have done work to modify their code base to the
IChoiceRenderer-less situation.
What are the pro's and con's of removing/keeping IChoiceRenderer?
Martijn
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martijn Dashorst <ma...@gmail.com>.
Ah... so I can undo my branch work for wicket 7 in our app :-). I'll try to
get some progress later this week on migrating our application to see if I
run into issues. I have a crazy work schedule currently so I'm a bit
strapped for time. It will clear up after Easter so expect some more
regularity in releases and a push for wicket 7 around that time.
Martijn
On Mon, Mar 24, 2014 at 9:33 AM, Martin Grigorov <mg...@apache.org>wrote:
> I've restored IChoiceRenderer interface so users can still use Enum based
> singletons.
>
> Further refactorings should be done in a separate ticket.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Mar 19, 2014 at 11:58 AM, Sven Meier <sv...@meiers.net> wrote:
>
> > Hi Martin,
> >
> > I'm +1 on releasing 7.x soon.
> >
> > ListMultipleChoice#getModelValue() and
> AbstractSingleSelectChoice#getModelValue()
> > are still problematic though:
> > Both call getChoices().indexOf(object), thus any non-primitive option has
> > to implement #equals() :(.
> >
> > How about leaving IChoiceRenderer to do the actual rendering part (i.e.
> > #getDisplayValue()) only ?
> > The conversion choice<->id (i.e. #getIdValue() and #getObject()) could be
> > moved into a converter instead.
> >
> > @Igor?
> >
> > Regards
> > Sven
> >
> >
> > On 03/19/2014 10:27 AM, Martin Grigorov wrote:
> >
> >> Sven, Igor,
> >>
> >> Do you have an agreement how IChoiceRenderer should look like in Wicket
> >> 7.x
> >> ?
> >>
> >> I really like to release 7.0.0-M1 so we got some user feedback.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >>
> >>
> >> On Wed, Feb 26, 2014 at 8:10 PM, tetsuo <ro...@gmail.com>
> wrote:
> >>
> >> Sorry for the rant...
> >>>
> >>> The transition from 1.4 to 1.5 was awful (full of such minor breaking
> >>> changes), but not so afterwards, I know I'm overreacting. Probably it's
> >>> because it happened (a colleague complaining about all the compiling
> >>> errors
> >>> when upgrading from 1.4) last week :/
> >>>
> >>> And well... it's somewhat inevitable to avoid compiling errors when
> >>> evolving a framework that is strongly type-safe (which is a great
> plus).
> >>>
> >>> Sorry again.
> >>>
> >>> But I still like my enums, please keep the interfaces :)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mgrigorov@apache.org
> >>>
> >>>> wrote:
> >>>> On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com>
> >>>> wrote:
> >>>>
> >>>> Guillaume, you're right.
> >>>>>
> >>>>> Martin, sorry for the misunderstanding.
> >>>>>
> >>>>> Enums can't extend any classes besides Enum. But can implement
> >>>>>
> >>>> interfaces.
> >>>> Thanks! Now it is clear to me.
> >>>>
> >>>>
> >>>> I use Enums in lots of places, not as enums, but as singletons,
> because
> >>>>> they won't be serialized, won't carry unintended references, and use
> >>>>> virtually no memory in pages. Converters, Renderers, Validators,
> Models
> >>>>> (less so of the former, since it almost always needs state). If
> >>>>>
> >>>> IBehavior
> >>>
> >>>> still existed, and didn't have so many methods, I'd use enums to
> >>>>>
> >>>> implement
> >>>>
> >>>>> some of them, too.
> >>>>>
> >>>>> But my main complaint is not specific to this issue, however. I'm
> more
> >>>>> concerned about frequent breaking API changes with no practical
> >>>>>
> >>>> advantage.
> >>>>
> >>>>> Javascript/JavaScript, addComponent/add(Component) and the like. I'm
> at
> >>>>>
> >>>> the
> >>>>
> >>>>> point that I'm starting to feel unconfortable recommending Wicket to
> >>>>> people, because I know an year from now they will complain that they
> >>>>> upgraded a library and a thousand compiling errors appeared. 98% of
> >>>>>
> >>>> them
> >>>
> >>>> are very simple errors, but it's a daunting task neverthless.
> >>>>>
> >>>>>
> >>>>> Options:
> >>>> 1) Wicket devs stop developing Wicket so the API stays stable forever
> >>>> 2) application developers don't upgrade to next major version of
> Wicket
> >>>> 3) find the golden middle.
> >>>>
> >>>> I think we all agree that 3) is the best for all and that we (Wicket
> >>>>
> >>> devs)
> >>>
> >>>> try to follow it:
> >>>>
> >>>> - we use SemVer to make it easier for application developers to know
> >>>> when
> >>>> to expect API breaks and when to not expect such
> >>>> - we discuss most of the API breaks for major versions here in dev@.
> >>>> If there are issues identified on time we react! Even this change
> has
> >>>> been discussed before being made
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <
> >>>>>
> >>>> mgrigorov@apache.org
> >>>
> >>>> wrote:
> >>>>>> As Martijn explained all that is needed is:
> >>>>>> - s/implements/extends/
> >>>>>> - remove the leading 'I' from IChoiceRenderer
> >>>>>>
> >>>>>> If the interface is preserved then all custom impls will have to add
> >>>>>> implementation of the new method introduced with WICKET-663. This
> IMO
> >>>>>>
> >>>>> will
> >>>>>
> >>>>>> lead to more work for the application developers.
> >>>>>>
> >>>>>> As I said: I am not against restoring the interface, just don't see
> >>>>>>
> >>>>> its
> >>>
> >>>> value.
> >>>>>>
> >>>>>> Martin Grigorov
> >>>>>> Wicket Training and Consulting
> >>>>>>
> >>>>>>
> >>>>>> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
> >>>>>>
> >>>>> guillaume.smet@gmail.com
> >>>>>
> >>>>>> wrote:
> >>>>>>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
> >>>>>>>
> >>>>>> wrote:
> >>>>>
> >>>>>> Because... it's an unnecessary breaking change?
> >>>>>>>>
> >>>>>>> From what I understand of your previous post, you implements some
> >>>>>>>
> >>>>>> of
> >>>
> >>>> your converters in Enums, which you can do because IChoiceRenderer
> >>>>>>>
> >>>>>> is
> >>>
> >>>> currently an interface. And you won't be able to do it if it's a
> >>>>>>> class.
> >>>>>>>
> >>>>>>> Am I right?
> >>>>>>>
> >>>>>>>
> >
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
I've restored IChoiceRenderer interface so users can still use Enum based
singletons.
Further refactorings should be done in a separate ticket.
Martin Grigorov
Wicket Training and Consulting
On Wed, Mar 19, 2014 at 11:58 AM, Sven Meier <sv...@meiers.net> wrote:
> Hi Martin,
>
> I'm +1 on releasing 7.x soon.
>
> ListMultipleChoice#getModelValue() and AbstractSingleSelectChoice#getModelValue()
> are still problematic though:
> Both call getChoices().indexOf(object), thus any non-primitive option has
> to implement #equals() :(.
>
> How about leaving IChoiceRenderer to do the actual rendering part (i.e.
> #getDisplayValue()) only ?
> The conversion choice<->id (i.e. #getIdValue() and #getObject()) could be
> moved into a converter instead.
>
> @Igor?
>
> Regards
> Sven
>
>
> On 03/19/2014 10:27 AM, Martin Grigorov wrote:
>
>> Sven, Igor,
>>
>> Do you have an agreement how IChoiceRenderer should look like in Wicket
>> 7.x
>> ?
>>
>> I really like to release 7.0.0-M1 so we got some user feedback.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Wed, Feb 26, 2014 at 8:10 PM, tetsuo <ro...@gmail.com> wrote:
>>
>> Sorry for the rant...
>>>
>>> The transition from 1.4 to 1.5 was awful (full of such minor breaking
>>> changes), but not so afterwards, I know I'm overreacting. Probably it's
>>> because it happened (a colleague complaining about all the compiling
>>> errors
>>> when upgrading from 1.4) last week :/
>>>
>>> And well... it's somewhat inevitable to avoid compiling errors when
>>> evolving a framework that is strongly type-safe (which is a great plus).
>>>
>>> Sorry again.
>>>
>>> But I still like my enums, please keep the interfaces :)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mgrigorov@apache.org
>>>
>>>> wrote:
>>>> On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com>
>>>> wrote:
>>>>
>>>> Guillaume, you're right.
>>>>>
>>>>> Martin, sorry for the misunderstanding.
>>>>>
>>>>> Enums can't extend any classes besides Enum. But can implement
>>>>>
>>>> interfaces.
>>>> Thanks! Now it is clear to me.
>>>>
>>>>
>>>> I use Enums in lots of places, not as enums, but as singletons, because
>>>>> they won't be serialized, won't carry unintended references, and use
>>>>> virtually no memory in pages. Converters, Renderers, Validators, Models
>>>>> (less so of the former, since it almost always needs state). If
>>>>>
>>>> IBehavior
>>>
>>>> still existed, and didn't have so many methods, I'd use enums to
>>>>>
>>>> implement
>>>>
>>>>> some of them, too.
>>>>>
>>>>> But my main complaint is not specific to this issue, however. I'm more
>>>>> concerned about frequent breaking API changes with no practical
>>>>>
>>>> advantage.
>>>>
>>>>> Javascript/JavaScript, addComponent/add(Component) and the like. I'm at
>>>>>
>>>> the
>>>>
>>>>> point that I'm starting to feel unconfortable recommending Wicket to
>>>>> people, because I know an year from now they will complain that they
>>>>> upgraded a library and a thousand compiling errors appeared. 98% of
>>>>>
>>>> them
>>>
>>>> are very simple errors, but it's a daunting task neverthless.
>>>>>
>>>>>
>>>>> Options:
>>>> 1) Wicket devs stop developing Wicket so the API stays stable forever
>>>> 2) application developers don't upgrade to next major version of Wicket
>>>> 3) find the golden middle.
>>>>
>>>> I think we all agree that 3) is the best for all and that we (Wicket
>>>>
>>> devs)
>>>
>>>> try to follow it:
>>>>
>>>> - we use SemVer to make it easier for application developers to know
>>>> when
>>>> to expect API breaks and when to not expect such
>>>> - we discuss most of the API breaks for major versions here in dev@.
>>>> If there are issues identified on time we react! Even this change has
>>>> been discussed before being made
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <
>>>>>
>>>> mgrigorov@apache.org
>>>
>>>> wrote:
>>>>>> As Martijn explained all that is needed is:
>>>>>> - s/implements/extends/
>>>>>> - remove the leading 'I' from IChoiceRenderer
>>>>>>
>>>>>> If the interface is preserved then all custom impls will have to add
>>>>>> implementation of the new method introduced with WICKET-663. This IMO
>>>>>>
>>>>> will
>>>>>
>>>>>> lead to more work for the application developers.
>>>>>>
>>>>>> As I said: I am not against restoring the interface, just don't see
>>>>>>
>>>>> its
>>>
>>>> value.
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
>>>>>>
>>>>> guillaume.smet@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>>>
>>>>>> Because... it's an unnecessary breaking change?
>>>>>>>>
>>>>>>> From what I understand of your previous post, you implements some
>>>>>>>
>>>>>> of
>>>
>>>> your converters in Enums, which you can do because IChoiceRenderer
>>>>>>>
>>>>>> is
>>>
>>>> currently an interface. And you won't be able to do it if it's a
>>>>>>> class.
>>>>>>>
>>>>>>> Am I right?
>>>>>>>
>>>>>>>
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Mar 19, 2014 at 2:58 AM, Sven Meier <sv...@meiers.net> wrote:
> Hi Martin,
>
> I'm +1 on releasing 7.x soon.
>
> ListMultipleChoice#getModelValue() and
> AbstractSingleSelectChoice#getModelValue() are still problematic though:
> Both call getChoices().indexOf(object), thus any non-primitive option has to
> implement #equals() :(.
so thats where the code should be fixed, instead of unrolling changes
that make perfect sense... the choice renderer can do this conversion,
since it is also the place that does the complementary conversion
already.
the reliance on the index is a stupid one imho. in real world there is
very rarely a usecase where a List is stable across requests. we
should remove the usage of index altogether from these components. for
usecases where the index is actually usable the renderer can use it
since it has access to it since it has access to the list model.
> How about leaving IChoiceRenderer to do the actual rendering part (i.e.
> #getDisplayValue()) only ?
> The conversion choice<->id (i.e. #getIdValue() and #getObject()) could be
> moved into a converter instead.
this is not really a usecase for converters. they are meant to convert
request values to objects. the problem is the choice renderer is
already doing half of this conversion in getIdValue(), so it does not
make sense to me to use the renderer for one half of the conversion
and converter for the other half. this needs to be made consistent,
either move all of it into renderer or move all of it into converter.
the renderer seemed a more logical place to me for this particular
component.
>
> @Igor?
>
> Regards
> Sven
>
>
> On 03/19/2014 10:27 AM, Martin Grigorov wrote:
>>
>> Sven, Igor,
>>
>> Do you have an agreement how IChoiceRenderer should look like in Wicket
>> 7.x
>> ?
>>
>> I really like to release 7.0.0-M1 so we got some user feedback.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Wed, Feb 26, 2014 at 8:10 PM, tetsuo <ro...@gmail.com> wrote:
>>
>>> Sorry for the rant...
>>>
>>> The transition from 1.4 to 1.5 was awful (full of such minor breaking
>>> changes), but not so afterwards, I know I'm overreacting. Probably it's
>>> because it happened (a colleague complaining about all the compiling
>>> errors
>>> when upgrading from 1.4) last week :/
>>>
>>> And well... it's somewhat inevitable to avoid compiling errors when
>>> evolving a framework that is strongly type-safe (which is a great plus).
>>>
>>> Sorry again.
>>>
>>> But I still like my enums, please keep the interfaces :)
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mgrigorov@apache.org
>>>>
>>>> wrote:
>>>> On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com> wrote:
>>>>
>>>>> Guillaume, you're right.
>>>>>
>>>>> Martin, sorry for the misunderstanding.
>>>>>
>>>>> Enums can't extend any classes besides Enum. But can implement
>>>>
>>>> interfaces.
>>>> Thanks! Now it is clear to me.
>>>>
>>>>
>>>>> I use Enums in lots of places, not as enums, but as singletons, because
>>>>> they won't be serialized, won't carry unintended references, and use
>>>>> virtually no memory in pages. Converters, Renderers, Validators, Models
>>>>> (less so of the former, since it almost always needs state). If
>>>
>>> IBehavior
>>>>>
>>>>> still existed, and didn't have so many methods, I'd use enums to
>>>>
>>>> implement
>>>>>
>>>>> some of them, too.
>>>>>
>>>>> But my main complaint is not specific to this issue, however. I'm more
>>>>> concerned about frequent breaking API changes with no practical
>>>>
>>>> advantage.
>>>>>
>>>>> Javascript/JavaScript, addComponent/add(Component) and the like. I'm at
>>>>
>>>> the
>>>>>
>>>>> point that I'm starting to feel unconfortable recommending Wicket to
>>>>> people, because I know an year from now they will complain that they
>>>>> upgraded a library and a thousand compiling errors appeared. 98% of
>>>
>>> them
>>>>>
>>>>> are very simple errors, but it's a daunting task neverthless.
>>>>>
>>>>>
>>>> Options:
>>>> 1) Wicket devs stop developing Wicket so the API stays stable forever
>>>> 2) application developers don't upgrade to next major version of Wicket
>>>> 3) find the golden middle.
>>>>
>>>> I think we all agree that 3) is the best for all and that we (Wicket
>>>
>>> devs)
>>>>
>>>> try to follow it:
>>>>
>>>> - we use SemVer to make it easier for application developers to know
>>>> when
>>>> to expect API breaks and when to not expect such
>>>> - we discuss most of the API breaks for major versions here in dev@.
>>>> If there are issues identified on time we react! Even this change has
>>>> been discussed before being made
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <
>>>
>>> mgrigorov@apache.org
>>>>>>
>>>>>> wrote:
>>>>>> As Martijn explained all that is needed is:
>>>>>> - s/implements/extends/
>>>>>> - remove the leading 'I' from IChoiceRenderer
>>>>>>
>>>>>> If the interface is preserved then all custom impls will have to add
>>>>>> implementation of the new method introduced with WICKET-663. This IMO
>>>>>
>>>>> will
>>>>>>
>>>>>> lead to more work for the application developers.
>>>>>>
>>>>>> As I said: I am not against restoring the interface, just don't see
>>>
>>> its
>>>>>>
>>>>>> value.
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
>>>>>
>>>>> guillaume.smet@gmail.com
>>>>>>>
>>>>>>> wrote:
>>>>>>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
>>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> Because... it's an unnecessary breaking change?
>>>>>>>
>>>>>>> From what I understand of your previous post, you implements some
>>>
>>> of
>>>>>>>
>>>>>>> your converters in Enums, which you can do because IChoiceRenderer
>>>
>>> is
>>>>>>>
>>>>>>> currently an interface. And you won't be able to do it if it's a
>>>>>>> class.
>>>>>>>
>>>>>>> Am I right?
>>>>>>>
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
I'm +1 on releasing 7.x soon.
ListMultipleChoice#getModelValue() and
AbstractSingleSelectChoice#getModelValue() are still problematic though:
Both call getChoices().indexOf(object), thus any non-primitive option
has to implement #equals() :(.
How about leaving IChoiceRenderer to do the actual rendering part (i.e.
#getDisplayValue()) only ?
The conversion choice<->id (i.e. #getIdValue() and #getObject()) could
be moved into a converter instead.
@Igor?
Regards
Sven
On 03/19/2014 10:27 AM, Martin Grigorov wrote:
> Sven, Igor,
>
> Do you have an agreement how IChoiceRenderer should look like in Wicket 7.x
> ?
>
> I really like to release 7.0.0-M1 so we got some user feedback.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Feb 26, 2014 at 8:10 PM, tetsuo <ro...@gmail.com> wrote:
>
>> Sorry for the rant...
>>
>> The transition from 1.4 to 1.5 was awful (full of such minor breaking
>> changes), but not so afterwards, I know I'm overreacting. Probably it's
>> because it happened (a colleague complaining about all the compiling errors
>> when upgrading from 1.4) last week :/
>>
>> And well... it's somewhat inevitable to avoid compiling errors when
>> evolving a framework that is strongly type-safe (which is a great plus).
>>
>> Sorry again.
>>
>> But I still like my enums, please keep the interfaces :)
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mgrigorov@apache.org
>>> wrote:
>>> On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com> wrote:
>>>
>>>> Guillaume, you're right.
>>>>
>>>> Martin, sorry for the misunderstanding.
>>>>
>>>> Enums can't extend any classes besides Enum. But can implement
>>> interfaces.
>>> Thanks! Now it is clear to me.
>>>
>>>
>>>> I use Enums in lots of places, not as enums, but as singletons, because
>>>> they won't be serialized, won't carry unintended references, and use
>>>> virtually no memory in pages. Converters, Renderers, Validators, Models
>>>> (less so of the former, since it almost always needs state). If
>> IBehavior
>>>> still existed, and didn't have so many methods, I'd use enums to
>>> implement
>>>> some of them, too.
>>>>
>>>> But my main complaint is not specific to this issue, however. I'm more
>>>> concerned about frequent breaking API changes with no practical
>>> advantage.
>>>> Javascript/JavaScript, addComponent/add(Component) and the like. I'm at
>>> the
>>>> point that I'm starting to feel unconfortable recommending Wicket to
>>>> people, because I know an year from now they will complain that they
>>>> upgraded a library and a thousand compiling errors appeared. 98% of
>> them
>>>> are very simple errors, but it's a daunting task neverthless.
>>>>
>>>>
>>> Options:
>>> 1) Wicket devs stop developing Wicket so the API stays stable forever
>>> 2) application developers don't upgrade to next major version of Wicket
>>> 3) find the golden middle.
>>>
>>> I think we all agree that 3) is the best for all and that we (Wicket
>> devs)
>>> try to follow it:
>>>
>>> - we use SemVer to make it easier for application developers to know when
>>> to expect API breaks and when to not expect such
>>> - we discuss most of the API breaks for major versions here in dev@.
>>> If there are issues identified on time we react! Even this change has
>>> been discussed before being made
>>>
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <
>> mgrigorov@apache.org
>>>>> wrote:
>>>>> As Martijn explained all that is needed is:
>>>>> - s/implements/extends/
>>>>> - remove the leading 'I' from IChoiceRenderer
>>>>>
>>>>> If the interface is preserved then all custom impls will have to add
>>>>> implementation of the new method introduced with WICKET-663. This IMO
>>>> will
>>>>> lead to more work for the application developers.
>>>>>
>>>>> As I said: I am not against restoring the interface, just don't see
>> its
>>>>> value.
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>>
>>>>>
>>>>> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
>>>> guillaume.smet@gmail.com
>>>>>> wrote:
>>>>>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
>>>> wrote:
>>>>>>> Because... it's an unnecessary breaking change?
>>>>>> From what I understand of your previous post, you implements some
>> of
>>>>>> your converters in Enums, which you can do because IChoiceRenderer
>> is
>>>>>> currently an interface. And you won't be able to do it if it's a
>>>>>> class.
>>>>>>
>>>>>> Am I right?
>>>>>>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
Sven, Igor,
Do you have an agreement how IChoiceRenderer should look like in Wicket 7.x
?
I really like to release 7.0.0-M1 so we got some user feedback.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 8:10 PM, tetsuo <ro...@gmail.com> wrote:
> Sorry for the rant...
>
> The transition from 1.4 to 1.5 was awful (full of such minor breaking
> changes), but not so afterwards, I know I'm overreacting. Probably it's
> because it happened (a colleague complaining about all the compiling errors
> when upgrading from 1.4) last week :/
>
> And well... it's somewhat inevitable to avoid compiling errors when
> evolving a framework that is strongly type-safe (which is a great plus).
>
> Sorry again.
>
> But I still like my enums, please keep the interfaces :)
>
>
>
>
>
>
> On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com> wrote:
> >
> > > Guillaume, you're right.
> > >
> > > Martin, sorry for the misunderstanding.
> > >
> > > Enums can't extend any classes besides Enum. But can implement
> > interfaces.
> > >
> >
> > Thanks! Now it is clear to me.
> >
> >
> > >
> > > I use Enums in lots of places, not as enums, but as singletons, because
> > > they won't be serialized, won't carry unintended references, and use
> > > virtually no memory in pages. Converters, Renderers, Validators, Models
> > > (less so of the former, since it almost always needs state). If
> IBehavior
> > > still existed, and didn't have so many methods, I'd use enums to
> > implement
> > > some of them, too.
> > >
> > > But my main complaint is not specific to this issue, however. I'm more
> > > concerned about frequent breaking API changes with no practical
> > advantage.
> > > Javascript/JavaScript, addComponent/add(Component) and the like. I'm at
> > the
> > > point that I'm starting to feel unconfortable recommending Wicket to
> > > people, because I know an year from now they will complain that they
> > > upgraded a library and a thousand compiling errors appeared. 98% of
> them
> > > are very simple errors, but it's a daunting task neverthless.
> > >
> > >
> > Options:
> > 1) Wicket devs stop developing Wicket so the API stays stable forever
> > 2) application developers don't upgrade to next major version of Wicket
> > 3) find the golden middle.
> >
> > I think we all agree that 3) is the best for all and that we (Wicket
> devs)
> > try to follow it:
> >
> > - we use SemVer to make it easier for application developers to know when
> > to expect API breaks and when to not expect such
> > - we discuss most of the API breaks for major versions here in dev@.
> > If there are issues identified on time we react! Even this change has
> > been discussed before being made
> >
> >
> >
> >
> > >
> > >
> > >
> > >
> > > On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <
> mgrigorov@apache.org
> > > >wrote:
> > >
> > > > As Martijn explained all that is needed is:
> > > > - s/implements/extends/
> > > > - remove the leading 'I' from IChoiceRenderer
> > > >
> > > > If the interface is preserved then all custom impls will have to add
> > > > implementation of the new method introduced with WICKET-663. This IMO
> > > will
> > > > lead to more work for the application developers.
> > > >
> > > > As I said: I am not against restoring the interface, just don't see
> its
> > > > value.
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > >
> > > >
> > > > On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
> > > guillaume.smet@gmail.com
> > > > >wrote:
> > > >
> > > > > On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
> > > wrote:
> > > > > > Because... it's an unnecessary breaking change?
> > > > >
> > > > > From what I understand of your previous post, you implements some
> of
> > > > > your converters in Enums, which you can do because IChoiceRenderer
> is
> > > > > currently an interface. And you won't be able to do it if it's a
> > > > > class.
> > > > >
> > > > > Am I right?
> > > > >
> > > >
> > >
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by tetsuo <ro...@gmail.com>.
Sorry for the rant...
The transition from 1.4 to 1.5 was awful (full of such minor breaking
changes), but not so afterwards, I know I'm overreacting. Probably it's
because it happened (a colleague complaining about all the compiling errors
when upgrading from 1.4) last week :/
And well... it's somewhat inevitable to avoid compiling errors when
evolving a framework that is strongly type-safe (which is a great plus).
Sorry again.
But I still like my enums, please keep the interfaces :)
On Wed, Feb 26, 2014 at 1:34 PM, Martin Grigorov <mg...@apache.org>wrote:
> On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com> wrote:
>
> > Guillaume, you're right.
> >
> > Martin, sorry for the misunderstanding.
> >
> > Enums can't extend any classes besides Enum. But can implement
> interfaces.
> >
>
> Thanks! Now it is clear to me.
>
>
> >
> > I use Enums in lots of places, not as enums, but as singletons, because
> > they won't be serialized, won't carry unintended references, and use
> > virtually no memory in pages. Converters, Renderers, Validators, Models
> > (less so of the former, since it almost always needs state). If IBehavior
> > still existed, and didn't have so many methods, I'd use enums to
> implement
> > some of them, too.
> >
> > But my main complaint is not specific to this issue, however. I'm more
> > concerned about frequent breaking API changes with no practical
> advantage.
> > Javascript/JavaScript, addComponent/add(Component) and the like. I'm at
> the
> > point that I'm starting to feel unconfortable recommending Wicket to
> > people, because I know an year from now they will complain that they
> > upgraded a library and a thousand compiling errors appeared. 98% of them
> > are very simple errors, but it's a daunting task neverthless.
> >
> >
> Options:
> 1) Wicket devs stop developing Wicket so the API stays stable forever
> 2) application developers don't upgrade to next major version of Wicket
> 3) find the golden middle.
>
> I think we all agree that 3) is the best for all and that we (Wicket devs)
> try to follow it:
>
> - we use SemVer to make it easier for application developers to know when
> to expect API breaks and when to not expect such
> - we discuss most of the API breaks for major versions here in dev@.
> If there are issues identified on time we react! Even this change has
> been discussed before being made
>
>
>
>
> >
> >
> >
> >
> > On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <mgrigorov@apache.org
> > >wrote:
> >
> > > As Martijn explained all that is needed is:
> > > - s/implements/extends/
> > > - remove the leading 'I' from IChoiceRenderer
> > >
> > > If the interface is preserved then all custom impls will have to add
> > > implementation of the new method introduced with WICKET-663. This IMO
> > will
> > > lead to more work for the application developers.
> > >
> > > As I said: I am not against restoring the interface, just don't see its
> > > value.
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > >
> > >
> > > On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
> > guillaume.smet@gmail.com
> > > >wrote:
> > >
> > > > On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
> > wrote:
> > > > > Because... it's an unnecessary breaking change?
> > > >
> > > > From what I understand of your previous post, you implements some of
> > > > your converters in Enums, which you can do because IChoiceRenderer is
> > > > currently an interface. And you won't be able to do it if it's a
> > > > class.
> > > >
> > > > Am I right?
> > > >
> > >
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ro...@gmail.com> wrote:
> Guillaume, you're right.
>
> Martin, sorry for the misunderstanding.
>
> Enums can't extend any classes besides Enum. But can implement interfaces.
>
Thanks! Now it is clear to me.
>
> I use Enums in lots of places, not as enums, but as singletons, because
> they won't be serialized, won't carry unintended references, and use
> virtually no memory in pages. Converters, Renderers, Validators, Models
> (less so of the former, since it almost always needs state). If IBehavior
> still existed, and didn't have so many methods, I'd use enums to implement
> some of them, too.
>
> But my main complaint is not specific to this issue, however. I'm more
> concerned about frequent breaking API changes with no practical advantage.
> Javascript/JavaScript, addComponent/add(Component) and the like. I'm at the
> point that I'm starting to feel unconfortable recommending Wicket to
> people, because I know an year from now they will complain that they
> upgraded a library and a thousand compiling errors appeared. 98% of them
> are very simple errors, but it's a daunting task neverthless.
>
>
Options:
1) Wicket devs stop developing Wicket so the API stays stable forever
2) application developers don't upgrade to next major version of Wicket
3) find the golden middle.
I think we all agree that 3) is the best for all and that we (Wicket devs)
try to follow it:
- we use SemVer to make it easier for application developers to know when
to expect API breaks and when to not expect such
- we discuss most of the API breaks for major versions here in dev@.
If there are issues identified on time we react! Even this change has
been discussed before being made
>
>
>
>
> On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > As Martijn explained all that is needed is:
> > - s/implements/extends/
> > - remove the leading 'I' from IChoiceRenderer
> >
> > If the interface is preserved then all custom impls will have to add
> > implementation of the new method introduced with WICKET-663. This IMO
> will
> > lead to more work for the application developers.
> >
> > As I said: I am not against restoring the interface, just don't see its
> > value.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> >
> >
> > On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <
> guillaume.smet@gmail.com
> > >wrote:
> >
> > > On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com>
> wrote:
> > > > Because... it's an unnecessary breaking change?
> > >
> > > From what I understand of your previous post, you implements some of
> > > your converters in Enums, which you can do because IChoiceRenderer is
> > > currently an interface. And you won't be able to do it if it's a
> > > class.
> > >
> > > Am I right?
> > >
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by tetsuo <ro...@gmail.com>.
Guillaume, you're right.
Martin, sorry for the misunderstanding.
Enums can't extend any classes besides Enum. But can implement interfaces.
I use Enums in lots of places, not as enums, but as singletons, because
they won't be serialized, won't carry unintended references, and use
virtually no memory in pages. Converters, Renderers, Validators, Models
(less so of the former, since it almost always needs state). If IBehavior
still existed, and didn't have so many methods, I'd use enums to implement
some of them, too.
But my main complaint is not specific to this issue, however. I'm more
concerned about frequent breaking API changes with no practical advantage.
Javascript/JavaScript, addComponent/add(Component) and the like. I'm at the
point that I'm starting to feel unconfortable recommending Wicket to
people, because I know an year from now they will complain that they
upgraded a library and a thousand compiling errors appeared. 98% of them
are very simple errors, but it's a daunting task neverthless.
On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov <mg...@apache.org>wrote:
> As Martijn explained all that is needed is:
> - s/implements/extends/
> - remove the leading 'I' from IChoiceRenderer
>
> If the interface is preserved then all custom impls will have to add
> implementation of the new method introduced with WICKET-663. This IMO will
> lead to more work for the application developers.
>
> As I said: I am not against restoring the interface, just don't see its
> value.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <guillaume.smet@gmail.com
> >wrote:
>
> > On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com> wrote:
> > > Because... it's an unnecessary breaking change?
> >
> > From what I understand of your previous post, you implements some of
> > your converters in Enums, which you can do because IChoiceRenderer is
> > currently an interface. And you won't be able to do it if it's a
> > class.
> >
> > Am I right?
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Feb 26, 2014 at 8:00 AM, Sven Meier <sv...@meiers.net> wrote:
> To add another point to the discussion:
>
> IMHO (I)ChoiceRenderer in 7.x is broken anyway.
> As long as the user has to implement #equals() in his model objects *or*
> override #getModelValue(), the choice renderer API is not yet complete:
>
> @Override
> public String getModelValue()
> {
> final T object = getModelObject();
> if (object != null)
> {
> // >>> #indexOf() might be inefficient or fail depending on the
> #equals() implementation <<<<<
> int index = getChoices().indexOf(object);
> return getChoiceRenderer().getIdValue(object, index);
> }
> else
> {
> return "";
> }
> }
i am going to guess this doesnt often break because 99% of
implementations out there do not use the index parameter. personally i
think it should be removed from choice renderer, leave it to the user
to map. we can pass the entire collection of choices into methods on
choice renderer instead of passing in an index.
> I wonder whether (I)ChoiceRenderer is taking the wrong direction: It's meant
> to control the rendering of choices (hence its name).
> Everything else could be made (or already is) adjustable via protected
> methods in the choice component.
it has never been just the renderer because from the beginning it is
what maps objects to their ids, it only makes sense that it takes care
of the inverse mapping. mapping objects to ids is usually a function
of the data-store, so why have half of data-store specific code in
choice renderer, and half in the component hierarchy?
-igor
>
> Regards
> Sven
>
>
>
> On 02/26/2014 04:44 PM, Martin Grigorov wrote:
>>
>> As Martijn explained all that is needed is:
>> - s/implements/extends/
>> - remove the leading 'I' from IChoiceRenderer
>>
>> If the interface is preserved then all custom impls will have to add
>> implementation of the new method introduced with WICKET-663. This IMO will
>> lead to more work for the application developers.
>>
>> As I said: I am not against restoring the interface, just don't see its
>> value.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet
>> <gu...@gmail.com>wrote:
>>
>>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com> wrote:
>>>>
>>>> Because... it's an unnecessary breaking change?
>>>
>>> From what I understand of your previous post, you implements some of
>>> your converters in Enums, which you can do because IChoiceRenderer is
>>> currently an interface. And you won't be able to do it if it's a
>>> class.
>>>
>>> Am I right?
>>>
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Sven Meier <sv...@meiers.net>.
To add another point to the discussion:
IMHO (I)ChoiceRenderer in 7.x is broken anyway.
As long as the user has to implement #equals() in his model objects *or*
override #getModelValue(), the choice renderer API is not yet complete:
@Override
public String getModelValue()
{
final T object = getModelObject();
if (object != null)
{
// >>> #indexOf() might be inefficient or fail depending on
the #equals() implementation <<<<<
int index = getChoices().indexOf(object);
return getChoiceRenderer().getIdValue(object, index);
}
else
{
return "";
}
}
I wonder whether (I)ChoiceRenderer is taking the wrong direction: It's
meant to control the rendering of choices (hence its name).
Everything else could be made (or already is) adjustable via protected
methods in the choice component.
Regards
Sven
On 02/26/2014 04:44 PM, Martin Grigorov wrote:
> As Martijn explained all that is needed is:
> - s/implements/extends/
> - remove the leading 'I' from IChoiceRenderer
>
> If the interface is preserved then all custom impls will have to add
> implementation of the new method introduced with WICKET-663. This IMO will
> lead to more work for the application developers.
>
> As I said: I am not against restoring the interface, just don't see its
> value.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <gu...@gmail.com>wrote:
>
>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com> wrote:
>>> Because... it's an unnecessary breaking change?
>> From what I understand of your previous post, you implements some of
>> your converters in Enums, which you can do because IChoiceRenderer is
>> currently an interface. And you won't be able to do it if it's a
>> class.
>>
>> Am I right?
>>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
As Martijn explained all that is needed is:
- s/implements/extends/
- remove the leading 'I' from IChoiceRenderer
If the interface is preserved then all custom impls will have to add
implementation of the new method introduced with WICKET-663. This IMO will
lead to more work for the application developers.
As I said: I am not against restoring the interface, just don't see its
value.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 5:37 PM, Guillaume Smet <gu...@gmail.com>wrote:
> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com> wrote:
> > Because... it's an unnecessary breaking change?
>
> From what I understand of your previous post, you implements some of
> your converters in Enums, which you can do because IChoiceRenderer is
> currently an interface. And you won't be able to do it if it's a
> class.
>
> Am I right?
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Guillaume Smet <gu...@gmail.com>.
On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ro...@gmail.com> wrote:
> Because... it's an unnecessary breaking change?
>From what I understand of your previous post, you implements some of
your converters in Enums, which you can do because IChoiceRenderer is
currently an interface. And you won't be able to do it if it's a
class.
Am I right?
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
I was interested in the technical problem behind "I can't do this if it is
not an interface." ..
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 5:33 PM, tetsuo <ro...@gmail.com> wrote:
> Because... it's an unnecessary breaking change?
>
>
>
> On Wed, Feb 26, 2014 at 9:54 AM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > On Wed, Feb 26, 2014 at 2:52 PM, tetsuo <ro...@gmail.com> wrote:
> >
> > > +1 for keeping IChoiceRenderer.
> > >
> > > I often create Enums with a single value when I want a singleton (the
> JVM
> > > guarantees the single instance, and it takes less space in memory and
> > when
> > > serialized), and many of my custom choice renderers are like this. I
> > can't
> > > do this if it is not an interface.
> > >
> >
> > Why ?
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov <mgrigorov@apache.org
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > Igor suggested to remove the interface and I agreed.
> > > > For me there was no real benefit from the interface here.
> > > > Almost everything in Wicket uses ChoiceRenderer.
> > > > By using a class it is easier to add new logic. Otherwise tickets
> like
> > > > https://issues.apache.org/jira/browse/WICKET-663 will be moved to
> the
> > > next
> > > > major release and then forgotten.
> > > >
> > > > But I don't expect adding new methods in near future to this class
> so I
> > > am
> > > > not against reverting this.
> > > >
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > >
> > > >
> > > > On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier <sv...@meiers.net>
> wrote:
> > > >
> > > > > +1 for keeping IChoiceRenderer:
> > > > >
> > > > > Currently all renderers extend ChoiceRenderer. But
> EnumChoiceRenderer
> > > > > could be implemented on its own:
> > > > >
> > > > > public T getObject(String id, IModel<? extends List<? extends
> T>>
> > > > > choices)
> > > > > {
> > > > > if (choices.getObject().isEmpty())
> > > > > {
> > > > > return null;
> > > > > }
> > > > > else
> > > > > {
> > > > > return
> > > (T)Enum.valueOf(choices.getObject().get(0).getClass(),
> > > > > id);
> > > > > }
> > > > > }
> > > > >
> > > > > Other implementations could do so too, so why should they extend
> > > > > ChoiceRenderer? An interface would be suited much better for this.
> > > > >
> > > > > Regards
> > > > > Sven
> > > > >
> > > > >
> > > > >
> > > > > On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
> > > > >
> > > > >> While upgrading our application the biggest time sink for now was
> > > going
> > > > >> through our code base and fixing the issues that came from
> removing
> > > > >> IChoiceRenderer. While I don't mind the work (mostly search and
> > > > replace) I
> > > > >> would like to learn about the reasoning for removing the
> interface.
> > > > >>
> > > > >> In my previous trial Sven noticed that he'd like to see
> > > IChoiceRenderer
> > > > >> restored. I'd like to start the discussion and resolve it before
> we
> > > cut
> > > > a
> > > > >> 7-M1 release-to prevent having to go through the motions of
> > > > re-introducing
> > > > >> the interface after folks have done work to modify their code base
> > to
> > > > the
> > > > >> IChoiceRenderer-less situation.
> > > > >>
> > > > >> What are the pro's and con's of removing/keeping IChoiceRenderer?
> > > > >>
> > > > >> Martijn
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by tetsuo <ro...@gmail.com>.
Because... it's an unnecessary breaking change?
On Wed, Feb 26, 2014 at 9:54 AM, Martin Grigorov <mg...@apache.org>wrote:
> On Wed, Feb 26, 2014 at 2:52 PM, tetsuo <ro...@gmail.com> wrote:
>
> > +1 for keeping IChoiceRenderer.
> >
> > I often create Enums with a single value when I want a singleton (the JVM
> > guarantees the single instance, and it takes less space in memory and
> when
> > serialized), and many of my custom choice renderers are like this. I
> can't
> > do this if it is not an interface.
> >
>
> Why ?
>
>
> >
> >
> >
> >
> >
> > On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov <mgrigorov@apache.org
> > >wrote:
> >
> > > Hi,
> > >
> > > Igor suggested to remove the interface and I agreed.
> > > For me there was no real benefit from the interface here.
> > > Almost everything in Wicket uses ChoiceRenderer.
> > > By using a class it is easier to add new logic. Otherwise tickets like
> > > https://issues.apache.org/jira/browse/WICKET-663 will be moved to the
> > next
> > > major release and then forgotten.
> > >
> > > But I don't expect adding new methods in near future to this class so I
> > am
> > > not against reverting this.
> > >
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > >
> > >
> > > On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier <sv...@meiers.net> wrote:
> > >
> > > > +1 for keeping IChoiceRenderer:
> > > >
> > > > Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer
> > > > could be implemented on its own:
> > > >
> > > > public T getObject(String id, IModel<? extends List<? extends T>>
> > > > choices)
> > > > {
> > > > if (choices.getObject().isEmpty())
> > > > {
> > > > return null;
> > > > }
> > > > else
> > > > {
> > > > return
> > (T)Enum.valueOf(choices.getObject().get(0).getClass(),
> > > > id);
> > > > }
> > > > }
> > > >
> > > > Other implementations could do so too, so why should they extend
> > > > ChoiceRenderer? An interface would be suited much better for this.
> > > >
> > > > Regards
> > > > Sven
> > > >
> > > >
> > > >
> > > > On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
> > > >
> > > >> While upgrading our application the biggest time sink for now was
> > going
> > > >> through our code base and fixing the issues that came from removing
> > > >> IChoiceRenderer. While I don't mind the work (mostly search and
> > > replace) I
> > > >> would like to learn about the reasoning for removing the interface.
> > > >>
> > > >> In my previous trial Sven noticed that he'd like to see
> > IChoiceRenderer
> > > >> restored. I'd like to start the discussion and resolve it before we
> > cut
> > > a
> > > >> 7-M1 release-to prevent having to go through the motions of
> > > re-introducing
> > > >> the interface after folks have done work to modify their code base
> to
> > > the
> > > >> IChoiceRenderer-less situation.
> > > >>
> > > >> What are the pro's and con's of removing/keeping IChoiceRenderer?
> > > >>
> > > >> Martijn
> > > >>
> > > >>
> > > >
> > >
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
On Wed, Feb 26, 2014 at 2:52 PM, tetsuo <ro...@gmail.com> wrote:
> +1 for keeping IChoiceRenderer.
>
> I often create Enums with a single value when I want a singleton (the JVM
> guarantees the single instance, and it takes less space in memory and when
> serialized), and many of my custom choice renderers are like this. I can't
> do this if it is not an interface.
>
Why ?
>
>
>
>
>
> On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov <mgrigorov@apache.org
> >wrote:
>
> > Hi,
> >
> > Igor suggested to remove the interface and I agreed.
> > For me there was no real benefit from the interface here.
> > Almost everything in Wicket uses ChoiceRenderer.
> > By using a class it is easier to add new logic. Otherwise tickets like
> > https://issues.apache.org/jira/browse/WICKET-663 will be moved to the
> next
> > major release and then forgotten.
> >
> > But I don't expect adding new methods in near future to this class so I
> am
> > not against reverting this.
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> >
> >
> > On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier <sv...@meiers.net> wrote:
> >
> > > +1 for keeping IChoiceRenderer:
> > >
> > > Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer
> > > could be implemented on its own:
> > >
> > > public T getObject(String id, IModel<? extends List<? extends T>>
> > > choices)
> > > {
> > > if (choices.getObject().isEmpty())
> > > {
> > > return null;
> > > }
> > > else
> > > {
> > > return
> (T)Enum.valueOf(choices.getObject().get(0).getClass(),
> > > id);
> > > }
> > > }
> > >
> > > Other implementations could do so too, so why should they extend
> > > ChoiceRenderer? An interface would be suited much better for this.
> > >
> > > Regards
> > > Sven
> > >
> > >
> > >
> > > On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
> > >
> > >> While upgrading our application the biggest time sink for now was
> going
> > >> through our code base and fixing the issues that came from removing
> > >> IChoiceRenderer. While I don't mind the work (mostly search and
> > replace) I
> > >> would like to learn about the reasoning for removing the interface.
> > >>
> > >> In my previous trial Sven noticed that he'd like to see
> IChoiceRenderer
> > >> restored. I'd like to start the discussion and resolve it before we
> cut
> > a
> > >> 7-M1 release-to prevent having to go through the motions of
> > re-introducing
> > >> the interface after folks have done work to modify their code base to
> > the
> > >> IChoiceRenderer-less situation.
> > >>
> > >> What are the pro's and con's of removing/keeping IChoiceRenderer?
> > >>
> > >> Martijn
> > >>
> > >>
> > >
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by tetsuo <ro...@gmail.com>.
+1 for keeping IChoiceRenderer.
I often create Enums with a single value when I want a singleton (the JVM
guarantees the single instance, and it takes less space in memory and when
serialized), and many of my custom choice renderers are like this. I can't
do this if it is not an interface.
On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov <mg...@apache.org>wrote:
> Hi,
>
> Igor suggested to remove the interface and I agreed.
> For me there was no real benefit from the interface here.
> Almost everything in Wicket uses ChoiceRenderer.
> By using a class it is easier to add new logic. Otherwise tickets like
> https://issues.apache.org/jira/browse/WICKET-663 will be moved to the next
> major release and then forgotten.
>
> But I don't expect adding new methods in near future to this class so I am
> not against reverting this.
>
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier <sv...@meiers.net> wrote:
>
> > +1 for keeping IChoiceRenderer:
> >
> > Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer
> > could be implemented on its own:
> >
> > public T getObject(String id, IModel<? extends List<? extends T>>
> > choices)
> > {
> > if (choices.getObject().isEmpty())
> > {
> > return null;
> > }
> > else
> > {
> > return (T)Enum.valueOf(choices.getObject().get(0).getClass(),
> > id);
> > }
> > }
> >
> > Other implementations could do so too, so why should they extend
> > ChoiceRenderer? An interface would be suited much better for this.
> >
> > Regards
> > Sven
> >
> >
> >
> > On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
> >
> >> While upgrading our application the biggest time sink for now was going
> >> through our code base and fixing the issues that came from removing
> >> IChoiceRenderer. While I don't mind the work (mostly search and
> replace) I
> >> would like to learn about the reasoning for removing the interface.
> >>
> >> In my previous trial Sven noticed that he'd like to see IChoiceRenderer
> >> restored. I'd like to start the discussion and resolve it before we cut
> a
> >> 7-M1 release-to prevent having to go through the motions of
> re-introducing
> >> the interface after folks have done work to modify their code base to
> the
> >> IChoiceRenderer-less situation.
> >>
> >> What are the pro's and con's of removing/keeping IChoiceRenderer?
> >>
> >> Martijn
> >>
> >>
> >
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Igor suggested to remove the interface and I agreed.
For me there was no real benefit from the interface here.
Almost everything in Wicket uses ChoiceRenderer.
By using a class it is easier to add new logic. Otherwise tickets like
https://issues.apache.org/jira/browse/WICKET-663 will be moved to the next
major release and then forgotten.
But I don't expect adding new methods in near future to this class so I am
not against reverting this.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier <sv...@meiers.net> wrote:
> +1 for keeping IChoiceRenderer:
>
> Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer
> could be implemented on its own:
>
> public T getObject(String id, IModel<? extends List<? extends T>>
> choices)
> {
> if (choices.getObject().isEmpty())
> {
> return null;
> }
> else
> {
> return (T)Enum.valueOf(choices.getObject().get(0).getClass(),
> id);
> }
> }
>
> Other implementations could do so too, so why should they extend
> ChoiceRenderer? An interface would be suited much better for this.
>
> Regards
> Sven
>
>
>
> On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
>
>> While upgrading our application the biggest time sink for now was going
>> through our code base and fixing the issues that came from removing
>> IChoiceRenderer. While I don't mind the work (mostly search and replace) I
>> would like to learn about the reasoning for removing the interface.
>>
>> In my previous trial Sven noticed that he'd like to see IChoiceRenderer
>> restored. I'd like to start the discussion and resolve it before we cut a
>> 7-M1 release-to prevent having to go through the motions of re-introducing
>> the interface after folks have done work to modify their code base to the
>> IChoiceRenderer-less situation.
>>
>> What are the pro's and con's of removing/keeping IChoiceRenderer?
>>
>> Martijn
>>
>>
>
Re: Wicket 7: IChoiceRenderer restore or keep out?
Posted by Sven Meier <sv...@meiers.net>.
+1 for keeping IChoiceRenderer:
Currently all renderers extend ChoiceRenderer. But EnumChoiceRenderer
could be implemented on its own:
public T getObject(String id, IModel<? extends List<? extends T>>
choices)
{
if (choices.getObject().isEmpty())
{
return null;
}
else
{
return
(T)Enum.valueOf(choices.getObject().get(0).getClass(), id);
}
}
Other implementations could do so too, so why should they extend
ChoiceRenderer? An interface would be suited much better for this.
Regards
Sven
On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
> While upgrading our application the biggest time sink for now was going
> through our code base and fixing the issues that came from removing
> IChoiceRenderer. While I don't mind the work (mostly search and replace) I
> would like to learn about the reasoning for removing the interface.
>
> In my previous trial Sven noticed that he'd like to see IChoiceRenderer
> restored. I'd like to start the discussion and resolve it before we cut a
> 7-M1 release-to prevent having to go through the motions of re-introducing
> the interface after folks have done work to modify their code base to the
> IChoiceRenderer-less situation.
>
> What are the pro's and con's of removing/keeping IChoiceRenderer?
>
> Martijn
>