You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by "Oliver B. Fischer" <ma...@swe-blog.net> on 2014/01/07 15:37:28 UTC
Why is getDisplayValue in getDisplayValue final?
Hi,
I just tried to customize EnumChoiceRenderer and to override
getDisplayValue, but is final. Why?
Can I submit a patch to remove final?
Bye,
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by "Oliver B. Fischer" <ma...@swe-blog.net>.
I dont remember exactly, but I guess I did it four or five times. That
is not much but know what each of these is a hidden fork of the original
implementation.
I wish I had written my custom annotation @WicketFork for these classes ;-)
Bye,
Oliver
Am 08.01.14 10:07, schrieb Martin Grigorov:
> This is true.
> The good thing is that Wicket is open source and you can copy the class and
> modify it locally.
> If you want to remove the copied code later you will contact us and tell us
> your use case.
> This way we get some feedback from our users and improve either Wicket code
> or users' code :)
>
> How many times you had to copy code for this reason ?
> There are no many complains about this in the mailing lists or in Jira.
> Last few years we don't use 'final' as the in the early development of
> Wicket. But we cannot just go over the code and remove all finals. Some of
> them have to be final. But if the user gives us a good reason we will
> consider it.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Wed, Jan 8, 2014 at 10:40 AM, Oliver B. Fischer <ma...@swe-blog.net>wrote:
>
>> I see the good point in it but in the moment when I needed a different
>> behaviour it is still final. No one will wait for the next release if you
>> have to do it now.
>>
>> Bye,
>>
>> Oliver
>>
>> Am 07.01.14 16:54, schrieb Martin Grigorov:
>>
>> http://wicket.sourceforge.net/faqs.html#why-final
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
This is true.
The good thing is that Wicket is open source and you can copy the class and
modify it locally.
If you want to remove the copied code later you will contact us and tell us
your use case.
This way we get some feedback from our users and improve either Wicket code
or users' code :)
How many times you had to copy code for this reason ?
There are no many complains about this in the mailing lists or in Jira.
Last few years we don't use 'final' as the in the early development of
Wicket. But we cannot just go over the code and remove all finals. Some of
them have to be final. But if the user gives us a good reason we will
consider it.
Martin Grigorov
Wicket Training and Consulting
On Wed, Jan 8, 2014 at 10:40 AM, Oliver B. Fischer <ma...@swe-blog.net>wrote:
> I see the good point in it but in the moment when I needed a different
> behaviour it is still final. No one will wait for the next release if you
> have to do it now.
>
> Bye,
>
> Oliver
>
> Am 07.01.14 16:54, schrieb Martin Grigorov:
>
> http://wicket.sourceforge.net/faqs.html#why-final
>> this is the explanation of the designers of Wicket
>>
>> I agree with both sides
>> I don't think that there are too many finals in the code
>> usually if you explain why you need to remove the final we either remove
>> it
>> for the next release or explain a better way
>> Sven asked for the reason already
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Tue, Jan 7, 2014 at 5:21 PM, Steve <sh...@gmail.com> wrote:
>>
>> Have to agree with this. I've come across the 'final' issues many times
>>> in wicket and other libraries. It appears from my own experience with
>>> Wicket is that classes/methods are marked final if the developer can't
>>> think of a reason someone might want to extend it (Martin, I'm not
>>> actually referring to RawMarkup here, there's many other cases I've
>>> encountered both in wicket-el and completely unrelated coding
>>> adventures). IMHO this is an artificial limitation and they should
>>> only be marked final if the expected results of that method form part of
>>> a contract that could be broken if the behaviour of the implementing
>>> method differs from the original. In that case it is the responsibility
>>> of the overrider to deal with the implications ultimately but if can be
>>> dealt with explaining the contract clearly in the javadoc. That way if
>>> a downstream developer mucks it up it's on their own head and the wicket
>>> devs don't have to deal with the fallout of buggered up design.
>>>
>>> Again IMHO there are very few legitimate use cases for marking methods
>>> or classes final in an OS library. Closed source I can understand.
>>>
>>> On 08/01/14 00:53, Oliver B. Fischer wrote:
>>>
>>>> There are to much final methods in Wicket. This leads to copying code
>>>> instead of overriding only the methods you would like to change.
>>>>
>>>> Oliver
>>>>
>>>> Am 07.01.14 15:44, schrieb Martin Grigorov:
>>>>
>>>>> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov
>>>>> <mg...@apache.org>wrote:
>>>>>
>>>>> Hi,
>>>>>>
>>>>>> It is no more final in 7.x.
>>>>>>
>>>>>>
>>>>> Actually it is still final.
>>>>> I have been confused with another method.
>>>>>
>>>>>
>>>>> I don't mind removing final in 6.x too.
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>>
>>>>>>
>>>>>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer
>>>>>> <ma...@swe-blog.net>wrote:
>>>>>>
>>>>>> Hi,
>>>>>>>
>>>>>>> I just tried to customize EnumChoiceRenderer and to override
>>>>>>> getDisplayValue, but is final. Why?
>>>>>>>
>>>>>>> Can I submit a patch to remove final?
>>>>>>>
>>>>>>> Bye,
>>>>>>>
>>>>>>> Oliver
>>>>>>>
>>>>>>> ------------------------------------------------------------
>>>>>>> ---------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by "Oliver B. Fischer" <ma...@swe-blog.net>.
I see the good point in it but in the moment when I needed a different
behaviour it is still final. No one will wait for the next release if
you have to do it now.
Bye,
Oliver
Am 07.01.14 16:54, schrieb Martin Grigorov:
> http://wicket.sourceforge.net/faqs.html#why-final
> this is the explanation of the designers of Wicket
>
> I agree with both sides
> I don't think that there are too many finals in the code
> usually if you explain why you need to remove the final we either remove it
> for the next release or explain a better way
> Sven asked for the reason already
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, Jan 7, 2014 at 5:21 PM, Steve <sh...@gmail.com> wrote:
>
>> Have to agree with this. I've come across the 'final' issues many times
>> in wicket and other libraries. It appears from my own experience with
>> Wicket is that classes/methods are marked final if the developer can't
>> think of a reason someone might want to extend it (Martin, I'm not
>> actually referring to RawMarkup here, there's many other cases I've
>> encountered both in wicket-el and completely unrelated coding
>> adventures). IMHO this is an artificial limitation and they should
>> only be marked final if the expected results of that method form part of
>> a contract that could be broken if the behaviour of the implementing
>> method differs from the original. In that case it is the responsibility
>> of the overrider to deal with the implications ultimately but if can be
>> dealt with explaining the contract clearly in the javadoc. That way if
>> a downstream developer mucks it up it's on their own head and the wicket
>> devs don't have to deal with the fallout of buggered up design.
>>
>> Again IMHO there are very few legitimate use cases for marking methods
>> or classes final in an OS library. Closed source I can understand.
>>
>> On 08/01/14 00:53, Oliver B. Fischer wrote:
>>> There are to much final methods in Wicket. This leads to copying code
>>> instead of overriding only the methods you would like to change.
>>>
>>> Oliver
>>>
>>> Am 07.01.14 15:44, schrieb Martin Grigorov:
>>>> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov
>>>> <mg...@apache.org>wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> It is no more final in 7.x.
>>>>>
>>>>
>>>> Actually it is still final.
>>>> I have been confused with another method.
>>>>
>>>>
>>>>> I don't mind removing final in 6.x too.
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>>
>>>>>
>>>>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer
>>>>> <ma...@swe-blog.net>wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just tried to customize EnumChoiceRenderer and to override
>>>>>> getDisplayValue, but is final. Why?
>>>>>>
>>>>>> Can I submit a patch to remove final?
>>>>>>
>>>>>> Bye,
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
http://wicket.sourceforge.net/faqs.html#why-final
this is the explanation of the designers of Wicket
I agree with both sides
I don't think that there are too many finals in the code
usually if you explain why you need to remove the final we either remove it
for the next release or explain a better way
Sven asked for the reason already
Martin Grigorov
Wicket Training and Consulting
On Tue, Jan 7, 2014 at 5:21 PM, Steve <sh...@gmail.com> wrote:
> Have to agree with this. I've come across the 'final' issues many times
> in wicket and other libraries. It appears from my own experience with
> Wicket is that classes/methods are marked final if the developer can't
> think of a reason someone might want to extend it (Martin, I'm not
> actually referring to RawMarkup here, there's many other cases I've
> encountered both in wicket-el and completely unrelated coding
> adventures). IMHO this is an artificial limitation and they should
> only be marked final if the expected results of that method form part of
> a contract that could be broken if the behaviour of the implementing
> method differs from the original. In that case it is the responsibility
> of the overrider to deal with the implications ultimately but if can be
> dealt with explaining the contract clearly in the javadoc. That way if
> a downstream developer mucks it up it's on their own head and the wicket
> devs don't have to deal with the fallout of buggered up design.
>
> Again IMHO there are very few legitimate use cases for marking methods
> or classes final in an OS library. Closed source I can understand.
>
> On 08/01/14 00:53, Oliver B. Fischer wrote:
> > There are to much final methods in Wicket. This leads to copying code
> > instead of overriding only the methods you would like to change.
> >
> > Oliver
> >
> > Am 07.01.14 15:44, schrieb Martin Grigorov:
> >> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov
> >> <mg...@apache.org>wrote:
> >>
> >>> Hi,
> >>>
> >>> It is no more final in 7.x.
> >>>
> >>
> >> Actually it is still final.
> >> I have been confused with another method.
> >>
> >>
> >>> I don't mind removing final in 6.x too.
> >>>
> >>> Martin Grigorov
> >>> Wicket Training and Consulting
> >>>
> >>>
> >>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer
> >>> <ma...@swe-blog.net>wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> I just tried to customize EnumChoiceRenderer and to override
> >>>> getDisplayValue, but is final. Why?
> >>>>
> >>>> Can I submit a patch to remove final?
> >>>>
> >>>> Bye,
> >>>>
> >>>> Oliver
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Steve <sh...@gmail.com>.
Have to agree with this. I've come across the 'final' issues many times
in wicket and other libraries. It appears from my own experience with
Wicket is that classes/methods are marked final if the developer can't
think of a reason someone might want to extend it (Martin, I'm not
actually referring to RawMarkup here, there's many other cases I've
encountered both in wicket-el and completely unrelated coding
adventures). IMHO this is an artificial limitation and they should
only be marked final if the expected results of that method form part of
a contract that could be broken if the behaviour of the implementing
method differs from the original. In that case it is the responsibility
of the overrider to deal with the implications ultimately but if can be
dealt with explaining the contract clearly in the javadoc. That way if
a downstream developer mucks it up it's on their own head and the wicket
devs don't have to deal with the fallout of buggered up design.
Again IMHO there are very few legitimate use cases for marking methods
or classes final in an OS library. Closed source I can understand.
On 08/01/14 00:53, Oliver B. Fischer wrote:
> There are to much final methods in Wicket. This leads to copying code
> instead of overriding only the methods you would like to change.
>
> Oliver
>
> Am 07.01.14 15:44, schrieb Martin Grigorov:
>> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov
>> <mg...@apache.org>wrote:
>>
>>> Hi,
>>>
>>> It is no more final in 7.x.
>>>
>>
>> Actually it is still final.
>> I have been confused with another method.
>>
>>
>>> I don't mind removing final in 6.x too.
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>>
>>>
>>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer
>>> <ma...@swe-blog.net>wrote:
>>>
>>>> Hi,
>>>>
>>>> I just tried to customize EnumChoiceRenderer and to override
>>>> getDisplayValue, but is final. Why?
>>>>
>>>> Can I submit a patch to remove final?
>>>>
>>>> Bye,
>>>>
>>>> Oliver
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by "Oliver B. Fischer" <ma...@swe-blog.net>.
There are to much final methods in Wicket. This leads to copying code
instead of overriding only the methods you would like to change.
Oliver
Am 07.01.14 15:44, schrieb Martin Grigorov:
> On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov <mg...@apache.org>wrote:
>
>> Hi,
>>
>> It is no more final in 7.x.
>>
>
> Actually it is still final.
> I have been confused with another method.
>
>
>> I don't mind removing final in 6.x too.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>>
>>
>> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer <ma...@swe-blog.net>wrote:
>>
>>> Hi,
>>>
>>> I just tried to customize EnumChoiceRenderer and to override
>>> getDisplayValue, but is final. Why?
>>>
>>> Can I submit a patch to remove final?
>>>
>>> Bye,
>>>
>>> Oliver
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
On Tue, Jan 7, 2014 at 4:42 PM, Martin Grigorov <mg...@apache.org>wrote:
> Hi,
>
> It is no more final in 7.x.
>
Actually it is still final.
I have been confused with another method.
> I don't mind removing final in 6.x too.
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer <ma...@swe-blog.net>wrote:
>
>> Hi,
>>
>> I just tried to customize EnumChoiceRenderer and to override
>> getDisplayValue, but is final. Why?
>>
>> Can I submit a patch to remove final?
>>
>> Bye,
>>
>> Oliver
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
It is no more final in 7.x.
I don't mind removing final in 6.x too.
Martin Grigorov
Wicket Training and Consulting
On Tue, Jan 7, 2014 at 4:37 PM, Oliver B. Fischer <ma...@swe-blog.net>wrote:
> Hi,
>
> I just tried to customize EnumChoiceRenderer and to override
> getDisplayValue, but is final. Why?
>
> Can I submit a patch to remove final?
>
> Bye,
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Sven Meier <sv...@meiers.net>.
You have #resourceKey() and #postprocess() to override - what do you
need more?
Sven
On 01/07/2014 03:37 PM, Oliver B. Fischer wrote:
> Hi,
>
> I just tried to customize EnumChoiceRenderer and to override
> getDisplayValue, but is final. Why?
>
> Can I submit a patch to remove final?
>
> Bye,
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by "Oliver B. Fischer" <ma...@swe-blog.net>.
I see your point and I also think that it is very important to ensure
the contract your class or methods relies on.
But in such a case the method where the method must be final a
customization point should be provided to allow us the modify the part
of the method which is independent of the contract.
For example:
@Override
public final Object getDisplayValue(T object)
{
final String value = getDisplayValueRaw(object);
return postprocess(value);
}
getDisplayValueRaw() whould be the customization point and could be
overwritten by a developer without breaking the method contract.
Oliver
Am 09.01.14 00:12, schrieb Igor Vaynberg:
> the method is final because overriding it means you will most likely
> break the contract of the resourceKey and postprocess methods which
> are meant to be used by you to customze the behavior of
> getDisplayValue().
>
> so lets say you create subclass MyEnumChoiceRenderer with an
> overridden getDisplayValue() that no longer calls postprocess(). then
> someone subclasses your subclass and overrides postprocess() expecting
> it to be called (thats what the javadoc says) but it wont be, because
> you broke the contract.
>
> having getDisplayValue() be final prevents you from breaking this
> contract and saving hours of head scratching down the road.
>
> if you look at EnumChoiceRenderer without getDisplayValue() there is
> only one meaningful line of code left:
>
> return Classes.simpleName(object.getDeclaringClass()) + '.' + object.name();
>
> everything else is javadoc or declarations. so why all the fuss over a
> trivial line of code?
>
> -igor
>
> ps: ironically if you did want to override getDisplayValue() in a way
> that broke the contract you would have to make your subclass final so
> no one further down the road could subclass it...
>
>
> On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer <ma...@swe-blog.net> wrote:
>> Hi,
>>
>> I just tried to customize EnumChoiceRenderer and to override
>> getDisplayValue, but is final. Why?
>>
>> Can I submit a patch to remove final?
>>
>> Bye,
>>
>> Oliver
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Jan 10, 2014 at 9:41 AM, Martin Grigorov <mg...@apache.org>wrote:
>
>
>
> On Thu, Jan 9, 2014 at 11:32 PM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi Igor,
>> >
>> > While I see what you mean I think that often this is not the case. At
>> least
>> > when using open source library.
>> > Most of the time users/developers do not read Javadoc but use the code
>> > directly.
>>
>> this is not my experience. most users can barely attach javadoc to
>> their ide, not even speaking about source.
>
>
> here is where we think differently
> if the user is not experienced enough this is not a problem of the
> library/framework/OS (LFOS) (s)he uses
> if the LFOS stays in the way of the user/developer then the problem is in
> the LFOS
>
> now the question is whether the LFOS should provide a single (the proper)
> way to do something or it should provide a sane default way and let the
> user choose a better one for her/his use cases
> the user may choose a worse way but this is not something the LFOS should
> prevent on any price
> more experienced users appreciate the provided flexibility
>
> example from yesterday/today:
> - a user complains that ajax multipart form submit doesn't work for FF
> - I ask for a quickstart
> - the user creates a quickstart and realizes that the problem is in his
> custom code
> - the user apologies and continues his work
>
> I think users complain more when the LFOS doesn't allow them to do
> something good than when the LFOS doesn't prevent them to do something bad.
>
>
>>
>> > If I want to override a method I'd first consult with the source of the
>> > overridden method, not with the Javadoc of the overridden method or its
>> > super.
>>
>> if you consulted with the source you would see that there is no reason
>> to override that method directly as its functionality can be
>> completely replaced by overriding postprocess()... so why override the
>> original?
>>
>
> For example to prevent MissingResourceException that may be thrown if the
> app doesn't have a value for the resource key.
>
This reason seems good enough for me to remove 'final' from the signature
of #getDisplayValue() and deprecate #postprocess().
https://issues.apache.org/jira/browse/WICKET-5470
>
>>
>> -igor
>>
>>
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> >
>> >
>> > On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg <igor.vaynberg@gmail.com
>> >wrote:
>> >
>> >> the method is final because overriding it means you will most likely
>> >> break the contract of the resourceKey and postprocess methods which
>> >> are meant to be used by you to customze the behavior of
>> >> getDisplayValue().
>> >>
>> >> so lets say you create subclass MyEnumChoiceRenderer with an
>> >> overridden getDisplayValue() that no longer calls postprocess(). then
>> >> someone subclasses your subclass and overrides postprocess() expecting
>> >> it to be called (thats what the javadoc says) but it wont be, because
>> >> you broke the contract.
>> >>
>> >> having getDisplayValue() be final prevents you from breaking this
>> >> contract and saving hours of head scratching down the road.
>> >>
>> >> if you look at EnumChoiceRenderer without getDisplayValue() there is
>> >> only one meaningful line of code left:
>> >>
>> >> return Classes.simpleName(object.getDeclaringClass()) + '.' +
>> object.name
>> >> ();
>> >>
>> >> everything else is javadoc or declarations. so why all the fuss over a
>> >> trivial line of code?
>> >>
>> >> -igor
>> >>
>> >> ps: ironically if you did want to override getDisplayValue() in a way
>> >> that broke the contract you would have to make your subclass final so
>> >> no one further down the road could subclass it...
>> >>
>> >>
>> >> On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer <
>> mailsink@swe-blog.net>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > I just tried to customize EnumChoiceRenderer and to override
>> >> > getDisplayValue, but is final. Why?
>> >> >
>> >> > Can I submit a patch to remove final?
>> >> >
>> >> > Bye,
>> >> >
>> >> > Oliver
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> > For additional commands, e-mail: users-help@wicket.apache.org
>> >> >
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by "Oliver B. Fischer" <ma...@swe-blog.net>.
Am 10.01.14 08:41, schrieb Martin Grigorov:
>> if you consulted with the source you would see that there is no reason
>> to override that method directly as its functionality can be
>> completely replaced by overriding postprocess()... so why override the
>> original?
>>
>
> For example to prevent MissingResourceException that may be thrown if the
> app doesn't have a value for the resource key.
>
This is exactly my use case.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Jan 9, 2014 at 11:32 PM, Igor Vaynberg <ig...@gmail.com>wrote:
> On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi Igor,
> >
> > While I see what you mean I think that often this is not the case. At
> least
> > when using open source library.
> > Most of the time users/developers do not read Javadoc but use the code
> > directly.
>
> this is not my experience. most users can barely attach javadoc to
> their ide, not even speaking about source.
here is where we think differently
if the user is not experienced enough this is not a problem of the
library/framework/OS (LFOS) (s)he uses
if the LFOS stays in the way of the user/developer then the problem is in
the LFOS
now the question is whether the LFOS should provide a single (the proper)
way to do something or it should provide a sane default way and let the
user choose a better one for her/his use cases
the user may choose a worse way but this is not something the LFOS should
prevent on any price
more experienced users appreciate the provided flexibility
example from yesterday/today:
- a user complains that ajax multipart form submit doesn't work for FF
- I ask for a quickstart
- the user creates a quickstart and realizes that the problem is in his
custom code
- the user apologies and continues his work
I think users complain more when the LFOS doesn't allow them to do
something good than when the LFOS doesn't prevent them to do something bad.
>
> > If I want to override a method I'd first consult with the source of the
> > overridden method, not with the Javadoc of the overridden method or its
> > super.
>
> if you consulted with the source you would see that there is no reason
> to override that method directly as its functionality can be
> completely replaced by overriding postprocess()... so why override the
> original?
>
For example to prevent MissingResourceException that may be thrown if the
app doesn't have a value for the resource key.
>
> -igor
>
>
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> >
> >
> > On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg <igor.vaynberg@gmail.com
> >wrote:
> >
> >> the method is final because overriding it means you will most likely
> >> break the contract of the resourceKey and postprocess methods which
> >> are meant to be used by you to customze the behavior of
> >> getDisplayValue().
> >>
> >> so lets say you create subclass MyEnumChoiceRenderer with an
> >> overridden getDisplayValue() that no longer calls postprocess(). then
> >> someone subclasses your subclass and overrides postprocess() expecting
> >> it to be called (thats what the javadoc says) but it wont be, because
> >> you broke the contract.
> >>
> >> having getDisplayValue() be final prevents you from breaking this
> >> contract and saving hours of head scratching down the road.
> >>
> >> if you look at EnumChoiceRenderer without getDisplayValue() there is
> >> only one meaningful line of code left:
> >>
> >> return Classes.simpleName(object.getDeclaringClass()) + '.' +
> object.name
> >> ();
> >>
> >> everything else is javadoc or declarations. so why all the fuss over a
> >> trivial line of code?
> >>
> >> -igor
> >>
> >> ps: ironically if you did want to override getDisplayValue() in a way
> >> that broke the contract you would have to make your subclass final so
> >> no one further down the road could subclass it...
> >>
> >>
> >> On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer <
> mailsink@swe-blog.net>
> >> wrote:
> >> > Hi,
> >> >
> >> > I just tried to customize EnumChoiceRenderer and to override
> >> > getDisplayValue, but is final. Why?
> >> >
> >> > Can I submit a patch to remove final?
> >> >
> >> > Bye,
> >> >
> >> > Oliver
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> > For additional commands, e-mail: users-help@wicket.apache.org
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Igor Vaynberg <ig...@gmail.com>.
On Wed, Jan 8, 2014 at 11:41 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi Igor,
>
> While I see what you mean I think that often this is not the case. At least
> when using open source library.
> Most of the time users/developers do not read Javadoc but use the code
> directly.
this is not my experience. most users can barely attach javadoc to
their ide, not even speaking about source.
> If I want to override a method I'd first consult with the source of the
> overridden method, not with the Javadoc of the overridden method or its
> super.
if you consulted with the source you would see that there is no reason
to override that method directly as its functionality can be
completely replaced by overriding postprocess()... so why override the
original?
-igor
>
> Martin Grigorov
> Wicket Training and Consulting
>
>
> On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg <ig...@gmail.com>wrote:
>
>> the method is final because overriding it means you will most likely
>> break the contract of the resourceKey and postprocess methods which
>> are meant to be used by you to customze the behavior of
>> getDisplayValue().
>>
>> so lets say you create subclass MyEnumChoiceRenderer with an
>> overridden getDisplayValue() that no longer calls postprocess(). then
>> someone subclasses your subclass and overrides postprocess() expecting
>> it to be called (thats what the javadoc says) but it wont be, because
>> you broke the contract.
>>
>> having getDisplayValue() be final prevents you from breaking this
>> contract and saving hours of head scratching down the road.
>>
>> if you look at EnumChoiceRenderer without getDisplayValue() there is
>> only one meaningful line of code left:
>>
>> return Classes.simpleName(object.getDeclaringClass()) + '.' + object.name
>> ();
>>
>> everything else is javadoc or declarations. so why all the fuss over a
>> trivial line of code?
>>
>> -igor
>>
>> ps: ironically if you did want to override getDisplayValue() in a way
>> that broke the contract you would have to make your subclass final so
>> no one further down the road could subclass it...
>>
>>
>> On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer <ma...@swe-blog.net>
>> wrote:
>> > Hi,
>> >
>> > I just tried to customize EnumChoiceRenderer and to override
>> > getDisplayValue, but is final. Why?
>> >
>> > Can I submit a patch to remove final?
>> >
>> > Bye,
>> >
>> > Oliver
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> > For additional commands, e-mail: users-help@wicket.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Igor,
While I see what you mean I think that often this is not the case. At least
when using open source library.
Most of the time users/developers do not read Javadoc but use the code
directly.
If I want to override a method I'd first consult with the source of the
overridden method, not with the Javadoc of the overridden method or its
super.
Martin Grigorov
Wicket Training and Consulting
On Thu, Jan 9, 2014 at 1:12 AM, Igor Vaynberg <ig...@gmail.com>wrote:
> the method is final because overriding it means you will most likely
> break the contract of the resourceKey and postprocess methods which
> are meant to be used by you to customze the behavior of
> getDisplayValue().
>
> so lets say you create subclass MyEnumChoiceRenderer with an
> overridden getDisplayValue() that no longer calls postprocess(). then
> someone subclasses your subclass and overrides postprocess() expecting
> it to be called (thats what the javadoc says) but it wont be, because
> you broke the contract.
>
> having getDisplayValue() be final prevents you from breaking this
> contract and saving hours of head scratching down the road.
>
> if you look at EnumChoiceRenderer without getDisplayValue() there is
> only one meaningful line of code left:
>
> return Classes.simpleName(object.getDeclaringClass()) + '.' + object.name
> ();
>
> everything else is javadoc or declarations. so why all the fuss over a
> trivial line of code?
>
> -igor
>
> ps: ironically if you did want to override getDisplayValue() in a way
> that broke the contract you would have to make your subclass final so
> no one further down the road could subclass it...
>
>
> On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer <ma...@swe-blog.net>
> wrote:
> > Hi,
> >
> > I just tried to customize EnumChoiceRenderer and to override
> > getDisplayValue, but is final. Why?
> >
> > Can I submit a patch to remove final?
> >
> > Bye,
> >
> > Oliver
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Why is getDisplayValue in getDisplayValue final?
Posted by Igor Vaynberg <ig...@gmail.com>.
the method is final because overriding it means you will most likely
break the contract of the resourceKey and postprocess methods which
are meant to be used by you to customze the behavior of
getDisplayValue().
so lets say you create subclass MyEnumChoiceRenderer with an
overridden getDisplayValue() that no longer calls postprocess(). then
someone subclasses your subclass and overrides postprocess() expecting
it to be called (thats what the javadoc says) but it wont be, because
you broke the contract.
having getDisplayValue() be final prevents you from breaking this
contract and saving hours of head scratching down the road.
if you look at EnumChoiceRenderer without getDisplayValue() there is
only one meaningful line of code left:
return Classes.simpleName(object.getDeclaringClass()) + '.' + object.name();
everything else is javadoc or declarations. so why all the fuss over a
trivial line of code?
-igor
ps: ironically if you did want to override getDisplayValue() in a way
that broke the contract you would have to make your subclass final so
no one further down the road could subclass it...
On Tue, Jan 7, 2014 at 6:37 AM, Oliver B. Fischer <ma...@swe-blog.net> wrote:
> Hi,
>
> I just tried to customize EnumChoiceRenderer and to override
> getDisplayValue, but is final. Why?
>
> Can I submit a patch to remove final?
>
> Bye,
>
> Oliver
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org