Thanks Kalle!

That solved my ajax securing problem.

/Gunnar

Den tisdagen den 17:e januari 2012 skrev Kalle Korhonen<
kalle.o.korho...@gmail.com>:
> On Thu, Aug 25, 2011 at 1:08 AM, Gunnar Eketrapp
> <gunnar.eketr...@gmail.com> wrote:
>> I still havn't managde to get ajax calls to redirect.
>> I changed to reload as a I saw in this mailing list.
>> In Chromes debugger I can see that the timed out ajax call returns ..
>> {"script":"window.location.reload();"}
>> ... but nothing happens on the client side.
>> So the question is still open do I have to do something to enable this ?
>
> Hey Gunnar, in case you never solved this on your own since the issue
> resurfaced on one of my projects to my surprise. The behavior is
> version dependent, you might need to send a content key with the
> response to get the scripts executed, but if all you need is a
> redirect, it's better to respond simply with:
> os.write(("{\"redirectURL\":\"" + link.toAbsoluteURI() +
"\"}").getBytes());
>
> And to Howard, as explained at
>
http://stackoverflow.com/questions/282429/returning-redirect-as-response-to-xhr-request
,
> it's not possible for the client application to handle a 302. The
> browser handles it directly and all the client sees is a response to
> the redirected request.
>
> Kalle
>
>
>> 2011/8/24 Magnus Kvalheim <mag...@kvalheim.dk>
>>
>>> No sorry, that's not relevant for this. Eager to help, but I should
>>> have paid more attention to detail :)
>>>
>>> On Wed, Aug 24, 2011 at 8:33 AM, Magnus Kvalheim <mag...@kvalheim.dk>
>>> wrote:
>>>
>>> > I sometimes use a proxy for doing redirects.
>>> >
>>> > *public class RedirectProxy {*
>>> > * @Persist private String redirectURL;*
>>> > * @Inject private ComponentResources _resources;*
>>> > * Object onActivate(){*
>>> > * try {*
>>> > * URL url = new URL(redirectURL);*
>>> > * return url;*
>>> > * } catch (Exception e) {*
>>> > * // TODO: handle exception*
>>> > * } finally{*
>>> > * _resources.discardPersistentFieldChanges(); *
>>> > * }*
>>> > * return Index.class;*
>>> > * }*
>>> > * public void setRedirectURL(String redirectURL) {*
>>> > * this.redirectURL = redirectURL;*
>>> > * }*
>>> > *
>>> > *
>>> > * public String getRedirectURL() {*
>>> > * return redirectURL;*
>>> > * }*
>>> > *}*
>>> >
>>> > Then from an eventhandler:
>>> > *redirectProxy.setRedirectURL(u);*
>>> > *return redirectProxy;*
>>> >
>>> > It could perhaps be useful for this case?
>>> >
>>> > --magnus
>>> >
>>> > On Tue, Aug 23, 2011 at 11:00 PM, Gunnar Eketrapp <
>>> > gunnar.eketr...@gmail.com> wrote:
>>> >
>>> >> Hum .. this did not work so I guess I have to do something on the
client
>>> >> side as well ...
>>> >>
>>> >>           if (request.isXHR()) {
>>> >>                OutputStream os =
>>> >> response.getOutputStream("application/json;charset=UTF-8");
>>> >>                os.write(("{\"script\":\"window.location.replace('" +
>>> >> link.toAbsoluteURI() + "');\"}").getBytes());
>>> >>                os.close();
>>> >>            } else {
>>> >>                response.sendRedirect(link);
>>> >>             }
>>> >>
>>> >>
>>> >> 2011/8/23 Kalle Korhonen <kalle.o.korho...@gmail.com>
>>> >>
>>> >> > On Mon, Aug 22, 2011 at 4:42 PM, Howard Lewis Ship <
hls...@gmail.com>
>>> >> > wrote:
>>> >> > > Actually, perhaps Tapestry's client-side support should, by
default,
>>> >> > > handle 302 correctly.
>>> >> >
>>> >> > Yes, perhaps so. But the correctness is "in the eye of the
beholder".
>>> >> > It's clear that a 302 response to a non-ajax request always causes
a
>>> >> > redirect, but not necessarily so for an ajax request. If the
default
>>> >> > behavior was easily overridable then yes, why not. Perhaps I should
>>> >> > just bring tapestry-exceptionpage functionality to the core.
>>> >> >
>>> >> > Kalle
>>> >> >
>>> >> >
>>> >> > > Currently, Tapestry's JSON response for partial page updates
>>> includes
>>> >> > > a special key for performing a redirect.
>>> >> > >
>>> >> > > On Mon, Aug 22, 2011 at 2:20 PM, Kalle Korhonen
>>> >> > > <kalle.o.korho...@gmail.com> wrote:
>>> >> > >> On Mon, Aug 22, 2011 at 1:27 PM, Gunnar Eketrapp
>>> >> > >> <

Reply via email to