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 <s...@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 <ronald.tet...@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 <mgrigo...@apache.org >>> >>>> wrote: >>>> On Wed, Feb 26, 2014 at 6:21 PM, tetsuo <ronald.tet...@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 < >>>>> >>>> mgrigo...@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.s...@gmail.com >>>>> >>>>>> wrote: >>>>>>> On Wed, Feb 26, 2014 at 4:33 PM, tetsuo <ronald.tet...@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? >>>>>>> >>>>>>> >
