Ajaxifier updates

> Hi
>
> Together with Denis Defreyne I was working on Issue 724: add
> .pushState to ajaxifier [1]. We ran into an issue that the current
> Ajaxifier implementation has as well. Namely that the redirect from
> the action to the render continuation happens totally transparently to
> the JavaScript. There is so way to find out the URL to which the
> redirect happened. So Ajaxifier ended up saving the action URL. To
> counter this we changed WARenderPhaseContinuation to add a custom HTTP
> header if the request was made with the Ajaxifier. Thinking about it
> again I'm a bit uncomfortable with putting specific knowledge about
> the Ajaxifier into WARenderPhaseContinuation. Maybe a custom subclass
> would be a better option, however that would have to reside in
> Seaside-RenderLoop otherwise JQuery-Core would have to depend on
> Seaside-RenderLoop. Opinions?
>
> Also I would appreciate it if somebody knowledgeable in the area
> (Lukas?) could review our changes, the affected packages are
> Seaside-RenderLoop and JQuery-Core.
>
>  [1] http://code.google.com/p/seaside/issues/detail?id=724
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

> On Sat, Sep 1, 2012 at 5:33 PM, Lukas Renggli <[hidden email]> wrote:
>> Hi Philippe,
>>
>> Using the history API seems definitely a good idea.
>>
>> For the redirect I am missing the context. Why does the Ajaxifier need
>> to save the action URL? When using the back button you should not
>> trigger the actions again, but jump back to the render URL.
>
> Correct, but it used to save the action URL. The reason it did so is
> because there was no way of finding out the URL of the render
> continuation since all the links on the page are to action
> continuations. The Ajaxifier used to add a _n to the links and save
> those URLs. However that still means they are combined action/render
> pages which means the callbacks will be executed again. Removing the
> _n causes a redirect to the render continuation but there is no way in
> Javascript to find out to which page a redirect happened. That's why
> we added the header.
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev