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