No objections so far...
I'll apply the patch with the improvements mentioned in this thread.

On Tue, Jan 10, 2012 at 12:55 AM, Peter Ertl <[email protected]> wrote:
> Just to make the picture complete, I think one more reason we have an ART 
> provider was that we could basically have something like
>
>  MyAjaxRequestTarget
>
> and add additional methods to itt, e.g.:
>
> - MyAjaxRequestTarget#focus(FormComponent)
> - MyAjaxRequestTarget#highlightComponentWithYellowFadingFlash(Component comp)
>
>
> Am 09.01.2012 um 19:15 schrieb Igor Vaynberg:
>
>> findHandler()
>>
>> -igor
>>
>> On Mon, Jan 9, 2012 at 9:57 AM, Sven Meier <[email protected]> wrote:
>>> There are a few places where the active or next requestHandler is looked up
>>> by type. This could be:
>>>
>>> <T extends IRequestHandler> T RequestCycle#resolveHandler(Class<T>)
>>>
>>> This would result in a little more typing though, e.g. for Ajax:
>>>
>>>  RequestCycle.get().resolveHandler(IAjaxRequestHandler.class)
>>>
>>> Sven
>>>
>>>
>>> On 01/09/2012 06:22 PM, Martin Grigorov wrote:
>>>>
>>>> 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

Reply via email to