While upgrading our application the biggest time sink for now was going
through our code base and fixing the issues that came from removing
IChoiceRenderer. While I don't mind the work (mostly search and replace) I
would like to learn about the reasoning for removing the interface.
In my previous
+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,
Devs,
Recently, I wanted to integrate wicket-auth-roles with servlet 3.0
container security. What I ultimately did was create a simple SigninPage
as so:
public class LoginInterceptorPage extends WebPage {
public LoginInterceptorPage() {
continueToOriginalDestination();
}
}
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
14 matches
Mail list logo
