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
