On Wed, Mar 19, 2014 at 2: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() :(.
so thats where the code should be fixed, instead of unrolling changes that make perfect sense... the choice renderer can do this conversion, since it is also the place that does the complementary conversion already. the reliance on the index is a stupid one imho. in real world there is very rarely a usecase where a List is stable across requests. we should remove the usage of index altogether from these components. for usecases where the index is actually usable the renderer can use it since it has access to it since it has access to the list model. > 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. this is not really a usecase for converters. they are meant to convert request values to objects. the problem is the choice renderer is already doing half of this conversion in getIdValue(), so it does not make sense to me to use the renderer for one half of the conversion and converter for the other half. this needs to be made consistent, either move all of it into renderer or move all of it into converter. the renderer seemed a more logical place to me for this particular component. > > @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? >>>>>>> >
