+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
