wicket-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Grigorov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (WICKET-6159) Improve compatibility with non-Wicket Ajax in ServletWebRequest
Date Mon, 09 May 2016 08:38:13 GMT

    [ https://issues.apache.org/jira/browse/WICKET-6159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276113#comment-15276113

Martin Grigorov commented on WICKET-6159:

bq. Isn't that exactly what AbstractAjaxBehavior.getCallbackUrl is already doing on page rendering?
It provides the same relative URLs like are rendered for forms itself, links or whatever and
I simply request to those URLs. That works quite well for various calls I make currently.

No. The base url might be needed in the Ajax call you make to return some other links.

> 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
>            Priority: Minor
>         Attachments: WICKET-6159.patch
> 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

View raw message