Returns the url against which the client, usually the browser, will resolve relative urls in
the rendered markup. If the client is a browser this is the url in the browser's address bar.
Under normal circumstances the client and request (
#getUrl()) urls are the same.
Handling an Ajax request, however, is a good example of when they may be different.
Technologies such as XHR are free to request whatever url they wish without
modifying the client url; however, any produced urls will be evaluated by the client
against the client url - not against the request url.
Lets take a simple example:
Suppose we are on a client detail page. This page contains an Ajax link which opens a list of
client's orders. Each order has a link that goes to the order detail page.
The client detail page is located at
and the order detail page is located at
The Ajax link which renders the detail section is located at
Lets run through the execution and see what happens when the XHR request is processed:
request 1: /details/customer/15
client url: details/customer/15 (the url in the browser's address bar)
request url: details/customer/15
Wicket renders relative Ajax details anchor as ../../wicket/page?3
../../wicket/page?3 resolved against current client url details/customer/15 yields:
request 2: /wicket/page?3
client url: customer/15 (unchanged since XHRs requests dont change it)
request url: wicket/ajax/page?3
now Wicket has to render a relative url to /details/order/22. If Wicket renders
it against the request url it will be: ../order/22, and later evaluated on the
client will result in /customer/order/22 which is incorrect.
This is why implementations of
Request must track the client url, so that relative
urls can be rendered against the same url they will be evaluated against on the client -
which is not always the same as the request url. For example, Wicket's Ajax implementation
always sends the current client url in a header along with the XHR request so that Wicket can
correctly render relative urls against it.