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
>>
>>
>
