Oh, or just remove the 'final' from the methods! (I can suggest a
number of other cases it could also be done)

On Wed, Jan 11, 2012 at 8:32 PM, tetsuo <[email protected]> wrote:
> No, please not another breaking change just for the sake of it.
>
> It's cheap to rename things that exist in your codebase and you hit
> 'Ctrl+Shift+R', and Eclipse does it all for you. It's not that cheap
> to fix safely (which 'find|grep|wc' is not!) thousands of compiler
> errors spread across hundreds of classes, when you just drop a new
> version of the library and wait the IDE to scream in anger. And it's
> very expensive to fix things inside third-party (or even in-house)
> libraries.
>
> I'm all in favor of enhancing the framework and cleaning its
> internals, but breaking things just because it will be slightly (and
> arguable) more pleasing to the eye, is not something I agree with.
>
> I already had to fix tons of 'Javascript' to 'JavaScript' errors in my
> projects, and this is something I rarely use. AjaxRequestTarget is
> used extensively.
>
>
>
> A suggestion: make AjaxRequestTarget an interface.
>
> Sure, it won't be consistent with the 'ISomething' convention, but
> this change probably won't break almost any application code besides
> internal hooks someone dares to override in the WebApplication class.
>
> My 2 cents.
>
> Tetsuo
>
>
> On Tue, Jan 10, 2012 at 7:55 AM, Martin Grigorov <[email protected]> wrote:
>> On Tue, Jan 10, 2012 at 11:22 AM, Martijn Dashorst
>> <[email protected]> wrote:
>>> -1
>>>
>>> There is no reason other than esthetics for renaming
>>> AjaxRequestTarget. It is probably after Label and Link the most used
>>> API in our framework. This breaks all existing applications about a
>>> million times.
>>
>> It is not just renaming ART to ARH.
>> Introducing IAjaxRequestHandler actually requires changes in all
>> onAction() methods (onClick, onUpdate, ...). This is the bigger
>> change. Simple change, but I understand what you mean.
>>
>>>
>>> This is similar to renaming Form to something else, or Label to
>>> TextRenderingComponent. We can't just go about and willy nilly rename
>>> stuff because it is somewhat better. This works for minor APIs or
>>> relatively new APIs. But AjaxRequestTarget is as widely used as Label.
>>>
>>> For example our major 3 applications contain the following component counts:
>>>
>>>> find . -name "*.java" -type f -exec grep AjaxRequestTarget {} \; | grep -v 
>>>> "import" | wc -l
>>>    2671
>>>> find . -name "*.java" -type f -exec grep " Label" {} \; | grep -v "import" 
>>>> | wc -l
>>>    6333
>>>> find . -name "*.java" -type f -exec grep " Form" {} \; | grep -v "import" 
>>>> | wc -l
>>>    3264
>>>
>>> That is: 2671 times a use of AjaxRequestTarget. Every and each use
>>> must be renamed, but even if the change is just making
>>> AjaxRequestTarget an interface with existing API still available, this
>>> warrants 2671 times a check to see if nothing breaks.
>>
>> Any advanced editor can replace any occurrence of AjaxRequestTarget
>> with IAjaxRequestHandler for a few seconds in a directory recursively.
>> Running the tests after that is a normal flow of the development process.
>>
>>>
>>> Please suggest something that doesn't break the living hell out of our
>>> users' code base.
>>
>> Then I suggest to remove the 'final's from the method signatures in
>> AjaxRequestTarget.
>> If this is not acceptable then I'll close the ticket as "Won't fix".
>>
>>>
>>> Martijn
>>>
>>>
>>> On Mon, Jan 9, 2012 at 3:14 PM, Martin Grigorov <[email protected]> 
>>> wrote:
>>>> Hi,
>>>>
>>>> In https://issues.apache.org/jira/browse/WICKET-4326 I suggest to
>>>> introduce IAjaxRequestHander which is an interface for
>>>> AjaxRequestTarget.
>>>> It gives the possibility to be able to provide customized ART or
>>>> completely new one. This way it is much easier to use a mock for
>>>> testing too.
>>>>
>>>> Until now we had
>>>> org.apache.wicket.protocol.http.WebApplication#setAjaxRequestTargetProvider()
>>>> but it was useless because ART is mostly final (i.e. many methods in
>>>> it are final).
>>>>
>>>> The "bad" thing is that all onXyz() methods (like onEvent, onClick,
>>>> onUpdate, ...) need to change their signature to receive
>>>> IAjaxRequestHandler instead.
>>>> The fix is easy but depending on how much Ajax you use in your
>>>> application it may be a cumbersome task ...
>>>>
>>>> --
>>>> Martin Grigorov
>>>> jWeekend
>>>> Training, Consulting, Development
>>>> http://jWeekend.com
>>>
>>>
>>>
>>> --
>>> Become a Wicket expert, learn from the best: http://wicketinaction.com
>>
>>
>>
>> --
>> Martin Grigorov
>> jWeekend
>> Training, Consulting, Development
>> http://jWeekend.com

Reply via email to