On Wed, Feb 26, 2014 at 2:52 PM, tetsuo <ronald.tet...@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 <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 > > >> > > >> > > > > > >
