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
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
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
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
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
+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
Hi,
Igor suggested to remove the interface and I agreed.
For me there was no real benefit from the interface here.
Almost everything in Wicket uses ChoiceRenderer.
By using a class it is easier to add new logic. Otherwise tickets like
https://issues.apache.org/jira/browse/WICKET-663 will be moved
+1 for keeping IChoiceRenderer.
I often create Enums with a single value when I want a singleton (the JVM
guarantees the single instance, and it takes less space in memory and when
serialized), and many of my custom choice renderers are like this. I can't
do this if it is not an interface.
On Wed, Feb 26, 2014 at 2:52 PM, tetsuo ronald.tet...@gmail.com wrote:
+1 for keeping IChoiceRenderer.
I often create Enums with a single value when I want a singleton (the JVM
guarantees the single instance, and it takes less space in memory and when
serialized), and many of my custom
I was interested in the technical problem behind I can't do this if it is
not an interface. ..
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 5:33 PM, tetsuo ronald.tet...@gmail.com wrote:
Because... it's an unnecessary breaking change?
On Wed, Feb 26, 2014 at 9:54
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
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
To add another point to the discussion:
IMHO (I)ChoiceRenderer in 7.x is broken anyway.
As long as the user has to implement #equals() in his model objects *or*
override #getModelValue(), the choice renderer API is not yet complete:
@Override
public String getModelValue()
{
On Wed, Feb 26, 2014 at 8:00 AM, Sven Meier s...@meiers.net wrote:
To add another point to the discussion:
IMHO (I)ChoiceRenderer in 7.x is broken anyway.
As long as the user has to implement #equals() in his model objects *or*
override #getModelValue(), the choice renderer API is not yet
Guillaume, you're right.
Martin, sorry for the misunderstanding.
Enums can't extend any classes besides Enum. But can implement interfaces.
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
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,
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
17 matches
Mail list logo
