+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 <mgrigo...@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 <s...@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
> >>
> >>
> >
>

Reply via email to