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
