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 >>> >>> >>> >>
