Hi,
I have a legacy web app which uses some pieces of Wicket and plain
jQuery to do some Ajax, but without any Wicket specific JS. The
glue between both is simply using AjaxBehavior to register some
callbacks and that works fine.
The problem I have currently is that Wicket thinks in some places that
Ajax always means using Wicket JS as well and checks for special
headers. One such place is WebRequest.isAjax, which is used e.g. to
determine if a special error handler should be invoked, which it
should in my case so I reimplemented isAjax.
The problem is that ServletWebRequest.getClientUrl makes the same
assumptions and throws exceptions if needed headers are missing. But
throwing those exceptions is unnecessary in my case, because the
non-Ajax behavior of that method simply works.
So I would suggest enhancing WebRequest to provide isAjax and some
kind of isWicketAjax to distinguish both situations from each other.
getClientUrl could than simply take isWicketAjax into account for its
special behavior and use the "non-Ajax" approach like it did before
else.
Currently I can achieve this only with a messy hack in my
implementation of WebRequest.isAjax, which returns false if called
from getClientUrl. Instead, the mentioned distinction should be of
general use for all applications dealing with Wicket and non-Wicket
parts.
Any thoughts on this?
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
