[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=15276092#comment-15276092 ] 

Thorsten Schöning edited comment on WICKET-6159 at 5/9/16 8:16 AM:
-------------------------------------------------------------------

{QUOTE}
The checks for "isAjax" are needed so that Wicket knows whether to construct AjaxRequestHandler and therefore return the special <ajax-response> instead of repainting the whole page.
{QUOTE}

Isn't that only the case if one uses Wicket-JS? I don't, I use e.g. third party JS libs with plain AbstraxtAjaxBehavior and return some JSON structure, simply because the lib needs it this way. And that's the whole point: There are some use cases where people need to operate outside of the Wicket world. And currently this works well, besides some places like the ones mentioned in this enhancement.

{QUOTE}
Wicket doesn't need to know whether this request is made with XmlHttpRequest, XDomainRequest, IFrame or any other type of request.
{QUOTE}

I tend to disagree, but that's not the point: The problem is that Wicket believes that anything which is Ajax is coming from Wicket-JS to acess some special headers/params and in my mind that is an unnecessary limitation. If I decide that more than Wicket-JS is Ajax, I can implement such checks on my own and docs of isAjax explicitly mention such cases, but at least in ServletWebRequest.getClientUrl Wicket makes unnecessary assumptions. If Wicket needs some special headers to work properly in some cases that is absolutely OK of course, but in my Ajax style requests those headers are simply not needed and Wicket still works properly.

{QUOTE}
What exactly would be the benefit of having two methods - isAjax() and isWicketAjax() ?
{QUOTE}

Easier integration with legacy apps and non-Wicket-Ajax and the problem in ServletWebRequest.getClientUrl could be solved easily: Just access the headers only if Wicket-Ajax is requested, else not. This way I wouldn't need a (messy) workaround to achieve exactly that to get my currently working behavior.

{QUOTE}
What your jQuery request needs to do with the page?
{QUOTE}

Nothing, it is totally independent and only requesting some data in one case, where an AbstractAjaxBehavior is used to provide the needed callback into the app and output some JSON. In other cases I don't even return any data, just execute some server side logic in terms of "fire&forget". But in both cases exceptions can occure of course and it would be fine if Wicket wouldn't output a complete HTML file in such a case, so I changed isAjax to recognize my requests and stumbled accross ServletWebRequest.getClientUrl...

{QUOTE}
And what kind of response does it expect ?
{QUOTE}

Some plain, custom JSON structure or even nothing, depends on the used lib.

{QUOTE}
Why it is not OK for you just to add "wicket-ajax" to the request headers and/or parameters ?
{QUOTE}

Isn't it better to solve such a limitation server side at only one place instead of needing to think of this whereever I issue Ajax requests on the client in all applications I might have? I don't need those headers/params and the fun fact is that even Wicket doesn't: The approach in the patch works well currently and doesn't seem to break any tests. The interesting question is if Wicket would benefit of the distinction made in general or not. And I think it would, because you still don't need to test for XmlHttpRequest or such, leave that to "us", only don't assume that all Ajax is coming from Wicket-JS. That is unnecessary, what you really want to know is if your headers/params are available and that's only the case and safe to assume in case of "isWicketAjax".

Of course it would be great if I wouldn't need to implement a check for e.g. XmlHttpRequest on my own as well, because I think a general "isAjax" should check those requests too, but I can live with that.

{QUOTE}
Additionally when making an Ajax request you need to provide the current page's baseUrl so Wicket could generate proper relative urls. If you don't provide this information then the chances something to break are high.
{QUOTE}

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.


was (Author: tschoening):
{QUOTE}
The checks for "isAjax" are needed so that Wicket knows whether to construct AjaxRequestHandler and therefore return the special <ajax-response> instead of repainting the whole page.
{QUOTE}

Isn't that only the case if one uses Wicket-JS? I don't, I use e.g. third party JS libs with plain AbstraxtAjaxBehavior and return some JSON structure, simply because the lib needs it this way. And that's the whole point: There are some use cases where people need to operate outside of the Wicket world. And currently this works well, besides some places like the ones mentioned in this enhancement.

{CODE}
Wicket doesn't need to know whether this request is made with XmlHttpRequest, XDomainRequest, IFrame or any other type of request.
{CODE}

I tend to disagree, but that's not the point: The problem is that Wicket believes that anything which is Ajax is coming from Wicket-JS to acess some special headers/params and in my mind that is an unnecessary limitation. If I decide that more than Wicket-JS is Ajax, I can implement such checks on my own and docs of isAjax explicitly mention such cases, but at least in ServletWebRequest.getClientUrl Wicket makes unnecessary assumptions. If Wicket needs some special headers to work properly in some cases that is absolutely OK of course, but in my Ajax style requests those headers are simply not needed and Wicket still works properly.

{CODE}
What exactly would be the benefit of having two methods - isAjax() and isWicketAjax() ?
{CODE}

Easier integration with legacy apps and non-Wicket-Ajax and the problem in ServletWebRequest.getClientUrl could be solved easily: Just access the headers only if Wicket-Ajax is requested, else not. This way I wouldn't need a (messy) workaround to achieve exactly that to get my currently working behavior.

{CODE}
What your jQuery request needs to do with the page?
{CODE}

Nothing, it is totally independent and only requesting some data in one case, where an AbstractAjaxBehavior is used to provide the needed callback into the app and output some JSON. In other cases I don't even return any data, just execute some server side logic in terms of "fire&forget". But in both cases exceptions can occure of course and it would be fine if Wicket wouldn't output a complete HTML file in such a case, so I changed isAjax to recognize my requests and stumbled accross ServletWebRequest.getClientUrl...

{CODE}
And what kind of response does it expect ?
{CODE}

Some plain, custom JSON structure or even nothing, depends on the used lib.

{CODE}
Why it is not OK for you just to add "wicket-ajax" to the request headers and/or parameters ?
{CODE}

Isn't it better to solve such a limitation server side at only one place instead of needing to think of this whereever I issue Ajax requests on the client in all applications I might have? I don't need those headers/params and the fun fact is that even Wicket doesn't: The approach in the patch works well currently and doesn't seem to break any tests. The interesting question is if Wicket would benefit of the distinction made in general or not. And I think it would, because you still don't need to test for XmlHttpRequest or such, leave that to "us", only don't assume that all Ajax is coming from Wicket-JS. That is unnecessary, what you really want to know is if your headers/params are available and that's only the case and safe to assume in case of "isWicketAjax".

Of course it would be great if I wouldn't need to implement a check for e.g. XmlHttpRequest on my own as well, because I think a general "isAjax" should check those requests too, but I can live with that.

{CODE}
Additionally when making an Ajax request you need to provide the current page's baseUrl so Wicket could generate proper relative urls. If you don't provide this information then the chances something to break are high.
{CODE}

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.

> 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
(v6.3.4#6332)