Re: Wicket 7: IChoiceRenderer restore or keep out?
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:
Re: Wicket 7: IChoiceRenderer restore or keep out?
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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.orgwrote: 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
Re: Wicket 7: IChoiceRenderer restore or keep out?
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
+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 null;
}
else
{
return
(T)Enum.valueOf(choices.getObject().get(0).getClass(), id);
}
}
Other implementations could do so too, so why should they extend
ChoiceRenderer? An interface would be suited much better for this.
Regards
Sven
On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
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 trial Sven noticed that he'd like to see IChoiceRenderer
restored. I'd like to start the discussion and resolve it before we cut a
7-M1 release-to prevent having to go through the motions of re-introducing
the interface after folks have done work to modify their code base to the
IChoiceRenderer-less situation.
What are the pro's and con's of removing/keeping IChoiceRenderer?
Martijn
Re: Wicket 7: IChoiceRenderer restore or keep out?
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 to the next
major release and then forgotten.
But I don't expect adding new methods in near future to this class so I am
not against reverting this.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier s...@meiers.net wrote:
+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 null;
}
else
{
return (T)Enum.valueOf(choices.getObject().get(0).getClass(),
id);
}
}
Other implementations could do so too, so why should they extend
ChoiceRenderer? An interface would be suited much better for this.
Regards
Sven
On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
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 trial Sven noticed that he'd like to see IChoiceRenderer
restored. I'd like to start the discussion and resolve it before we cut a
7-M1 release-to prevent having to go through the motions of re-introducing
the interface after folks have done work to modify their code base to the
IChoiceRenderer-less situation.
What are the pro's and con's of removing/keeping IChoiceRenderer?
Martijn
Re: Wicket 7: IChoiceRenderer restore or keep out?
+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 7:45 AM, Martin Grigorov mgrigo...@apache.orgwrote:
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 to the next
major release and then forgotten.
But I don't expect adding new methods in near future to this class so I am
not against reverting this.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier s...@meiers.net wrote:
+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 null;
}
else
{
return (T)Enum.valueOf(choices.getObject().get(0).getClass(),
id);
}
}
Other implementations could do so too, so why should they extend
ChoiceRenderer? An interface would be suited much better for this.
Regards
Sven
On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
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 trial Sven noticed that he'd like to see IChoiceRenderer
restored. I'd like to start the discussion and resolve it before we cut
a
7-M1 release-to prevent having to go through the motions of
re-introducing
the interface after folks have done work to modify their code base to
the
IChoiceRenderer-less situation.
What are the pro's and con's of removing/keeping IChoiceRenderer?
Martijn
Re: Wicket 7: IChoiceRenderer restore or keep out?
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 choice renderers are like this. I can't
do this if it is not an interface.
Why ?
On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov mgrigo...@apache.org
wrote:
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 to the
next
major release and then forgotten.
But I don't expect adding new methods in near future to this class so I
am
not against reverting this.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier s...@meiers.net wrote:
+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 null;
}
else
{
return
(T)Enum.valueOf(choices.getObject().get(0).getClass(),
id);
}
}
Other implementations could do so too, so why should they extend
ChoiceRenderer? An interface would be suited much better for this.
Regards
Sven
On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
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 trial Sven noticed that he'd like to see
IChoiceRenderer
restored. I'd like to start the discussion and resolve it before we
cut
a
7-M1 release-to prevent having to go through the motions of
re-introducing
the interface after folks have done work to modify their code base to
the
IChoiceRenderer-less situation.
What are the pro's and con's of removing/keeping IChoiceRenderer?
Martijn
Re: Wicket 7: IChoiceRenderer restore or keep out?
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 AM, Martin Grigorov mgrigo...@apache.org
wrote:
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 choice renderers are like this. I
can't
do this if it is not an interface.
Why ?
On Wed, Feb 26, 2014 at 7:45 AM, Martin Grigorov mgrigo...@apache.org
wrote:
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 to
the
next
major release and then forgotten.
But I don't expect adding new methods in near future to this class
so I
am
not against reverting this.
Martin Grigorov
Wicket Training and Consulting
On Wed, Feb 26, 2014 at 12:36 PM, Sven Meier s...@meiers.net
wrote:
+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 null;
}
else
{
return
(T)Enum.valueOf(choices.getObject().get(0).getClass(),
id);
}
}
Other implementations could do so too, so why should they extend
ChoiceRenderer? An interface would be suited much better for this.
Regards
Sven
On 02/26/2014 11:23 AM, Martijn Dashorst wrote:
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 trial Sven noticed that he'd like to see
IChoiceRenderer
restored. I'd like to start the discussion and resolve it before
we
cut
a
7-M1 release-to prevent having to go through the motions of
re-introducing
the interface after folks have done work to modify their code base
to
the
IChoiceRenderer-less situation.
What are the pro's and con's of removing/keeping IChoiceRenderer?
Martijn
Re: Wicket 7: IChoiceRenderer restore or keep out?
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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.comwrote: 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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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()
{
final T object = getModelObject();
if (object != null)
{
// #indexOf() might be inefficient or fail depending on
the #equals() implementation
int index = getChoices().indexOf(object);
return getChoiceRenderer().getIdValue(object, index);
}
else
{
return ;
}
}
I wonder whether (I)ChoiceRenderer is taking the wrong direction: It's
meant to control the rendering of choices (hence its name).
Everything else could be made (or already is) adjustable via protected
methods in the choice component.
Regards
Sven
On 02/26/2014 04:44 PM, Martin Grigorov 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.comwrote:
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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 complete:
@Override
public String getModelValue()
{
final T object = getModelObject();
if (object != null)
{
// #indexOf() might be inefficient or fail depending on the
#equals() implementation
int index = getChoices().indexOf(object);
return getChoiceRenderer().getIdValue(object, index);
}
else
{
return ;
}
}
i am going to guess this doesnt often break because 99% of
implementations out there do not use the index parameter. personally i
think it should be removed from choice renderer, leave it to the user
to map. we can pass the entire collection of choices into methods on
choice renderer instead of passing in an index.
I wonder whether (I)ChoiceRenderer is taking the wrong direction: It's meant
to control the rendering of choices (hence its name).
Everything else could be made (or already is) adjustable via protected
methods in the choice component.
it has never been just the renderer because from the beginning it is
what maps objects to their ids, it only makes sense that it takes care
of the inverse mapping. mapping objects to ids is usually a function
of the data-store, so why have half of data-store specific code in
choice renderer, and half in the component hierarchy?
-igor
Regards
Sven
On 02/26/2014 04:44 PM, Martin Grigorov 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.comwrote:
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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 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. On Wed, Feb 26, 2014 at 12:44 PM, Martin Grigorov mgrigo...@apache.orgwrote: 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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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?
Re: Wicket 7: IChoiceRenderer restore or keep out?
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.orgwrote: 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?
