Ah... so I can undo my branch work for wicket 7 in our app :-). I'll try to get some progress later this week on migrating our application to see if I run into issues. I have a crazy work schedule currently so I'm a bit strapped for time. It will clear up after Easter so expect some more regularity in releases and a push for wicket 7 around that time.
Martijn On Mon, Mar 24, 2014 at 9:33 AM, Martin Grigorov <mgrigo...@apache.org>wrote: > 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? > >>>>>>> > >>>>>>> > > > -- Become a Wicket expert, learn from the best: http://wicketinaction.com
