[Seaside] Updating browser history from an ajax response

[Paul DeBruicker]

Oh man if only our past selves knew we really wanted Iliad apps what a world
this would be....



In my apps I use 

     $.fn.updateUrl = function(anId){
        
         if (typeof(window.history.pushState) == 'function') {
             var relativeUrl = $(this).attr('href');
             if(typeof(relativeUrl) =='undefined'){
                 relativeUrl =
document.location.pathname+document.location.search;
             };
             if(relativeUrl!=='javascript:void(0)' && relativeUrl !==
window.history.state){
                 window.history.pushState(relativeUrl, document.title,
relativeUrl);
             }
         }
     };

and call it as part of the onClick: script on anchors and buttons BEFORE
loading content via ajax.  

So the onClick: is 


onClick: html jQuery this updateUrl, (self doContentLoadingMagicOn: html)


Also it doesn't need to be a jQuery function but is because it was different
when I initially made it.  



Not sure its what you want to do but it definitely sets the window location
(url) to something that when you hit refresh gives you the same page you see
before you hit refresh (with updated server content, if anything there has
changed in the interim).






Siemen Baader wrote
> Hi,
> 
> Not really answering your questions, but I think this is what Iliad is
> for. There you have access to a restful URL on every (xhr) request and
> every WAComponent is transparently updated via xhr, including when you use
> call-answer. 
> 
> Just FYI. :)
> 
> Siemen
> 
> Sent from my iPhone
> 
>> On 12 Apr 2019, at 17.23, Johan Brichau <

> johan@

> > wrote:
>> 
>> Hi Esteban,
>> 
>> I’m interested in this too.
>> We have the same kind of application (I guess… using mostly Ajax updates,
>> I mean) but I have just been postponing a retry to address the
>> inconsistency with ajax, server state and the back button for years….
>> 
>> Within a callback, you can get at the #actionUrl on the renderer. 
>> Is that what you want?
>> 
>> I’m trying to dive into what would be required here… trying to understand
>> what you need:
>> Ajax requests always update the same continuation state in Seaside (i.e.
>> they do not create a new continuation)… so if you push that url to the
>> history after each ajax update, the back button will essentially request
>> the same but updated continuation from Seaside, meaning you should see
>> the state as it is in on the server, and not how it was before you made
>> the ajax request (which is what happens now).
>> 
>> Does that correspond to what you are trying to fix?
>> 
>> Johan
>> 
>>> On 12 Apr 2019, at 15:17, Esteban Maringolo <

> emaringolo@

> > wrote:
>>> 
>>> I have a Seaside application that is almost 100% AJAX driven to
>>> replace the visual components (no call/answer involved).
>>> 
>>> I plan to to use history.pushState() and history.replaceState()
>>> 
>>> My plan is to update the browser url after replacing some components,
>>> but using the URL building of the existing #updateUrl: (including
>>> _s/_k parameters and whatnot).
>>> 
>>> Is it possible to obtain the URL of the session presenter within the
>>> ajax response?
>>> 
>>> Thanks in advance,
>>> 
>>> Esteban A. Maringolo
>>> _______________________________________________
>>> seaside mailing list
>>> 

> seaside at .squeakfoundation

>>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> _______________________________________________
>> seaside mailing list
>> 

> seaside at .squeakfoundation

>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list

> seaside at .squeakfoundation

> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside





--
Sent from: http://forum.world.st/Seaside-General-f86180.html