One more thing:
currently we have : AjaxRequestTarget.get() which extracts the ART
from the scheduled IRequestTargets
I think we should move this code somewhere out.
Either:
class IAjaxRequestHandler {
public static class Current {
public static IAjaxRequestHandler get() { // the current code }
}
}
or
IAjaxRequestHandlerLocator {
public static IAjaxRequestHandler get() { // the current code }
}
Do you have better solution ?
On Mon, Jan 9, 2012 at 7:19 PM, Martin Grigorov <[email protected]> wrote:
> On Mon, Jan 9, 2012 at 6:59 PM, Igor Vaynberg <[email protected]> wrote:
>> On Mon, Jan 9, 2012 at 6:14 AM, 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.
>>
>> looks fine, as long as we take this opportunity to also rename
>> AjaxRequestTarget to AjaxRequestHandler to bring it in line. also the
>> inner listeners should also s/target/handler/
>
> agree
>
>>
>>> 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).
>>
>> its not useless, it lets applications register default listeners.
>
> for this we have
> org.apache.wicket.protocol.http.WebApplication#getAjaxRequestTargetListeners()
> :-)
>
>> overriding methods on the ART is dangerous. if you change the behavior
>> then none of the libraries that use ajax will work. this is why we
>> havent extracted the interface until now...there has to be one
>> consistent implementation.
>
> this is something I'm not quite convinced. if I replace a default impl
> of something then I'm responsible to make it working for my
> application needs
> if a user files a ticket that his impl doesn't work then I'll close it
> describing that this is not a problem we can solve. but often custom
> impls find what is missing in the abstractions so I find it useful
>
>>
>> -igor
>>
>>> 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
>
>
>
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> http://jWeekend.com
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
