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 <mgrigo...@apache.org> wrote:
> On Tue, Jan 10, 2012 at 11:22 AM, Martijn Dashorst
> <martijn.dasho...@gmail.com> 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 <mgrigo...@apache.org> 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
