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?
