[jira] [Updated] (WICKET-6159) Improve compatibility with non-Wicket Ajax in ServletWebRequest

["Thorsten Schöning (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WICKET-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thorsten Schöning updated WICKET-6159:
--------------------------------------
    Description: 
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.

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

Thanks for consideration!

There's a discussion on the mailing list as well:

http://mail-archives.apache.org/mod_mbox/wicket-users/201605.mbox/<554443622.20160503154911%40am-soft.de>

  was:
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.

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

Thanks for consideration!


> Improve compatibility with non-Wicket Ajax in ServletWebRequest
> ---------------------------------------------------------------
>
>                 Key: WICKET-6159
>                 URL: https://issues.apache.org/jira/browse/WICKET-6159
>             Project: Wicket
>          Issue Type: Improvement
>          Components: wicket
>    Affects Versions: 7.3.0
>            Reporter: Thorsten Schöning
>
> 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.
> Another 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.
> Thanks for consideration!
> There's a discussion on the mailing list as well:
> http://mail-archives.apache.org/mod_mbox/wicket-users/201605.mbox/<554443622.20160503154911%40am-soft.de>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)