How did you solve the ajax & back browser button problem?
Locked
How did you solve the ajax & back browser button problem?
 
|
Hi,
my application does much with ajax calls and because of this, my browser history is nearly empty. There are, indepently from pharo and seaside, several solutions for this problem described in the web. But after looking around for a while I want to ask how did (or how would) you solve this problem within pharo and seaside? I want that my users can click the back button and go to the "page before". Can I solve this with Seaside-REST? Which is the best way? Regards Sabine |
Re: How did you solve the ajax & back browser button problem?
|
Which Seaside version?
In 3.1 this code was implemented: https://code.google.com/p/seaside/issues/detail?id=724&can=1&q=history&colspec=ID%20Type%20Status%20Priority%20Version%20Platform%20Owner%20Summary%20Milestone
|
Re: How did you solve the ajax & back browser button problem?
|
|
In reply to this post by Sabine Manaa
Hi Sabine,
Aaaah... the joys of the back button server-side rendered ajax applications... As Paul points out, if you use the ajaxifier library, there is a solution that uses the html5 history API [1]. The ajaxifier library transforms Seaside callbacks into browser ajax requests on the client side. However, this means that they are still executed as full page requests in Seaside itself. If I remember correctly, it pushes the continuation key onto the state history stack. A back button press can then make a call to fetch the previous continuation. It makes the use of ajax transparant, but it also defeats many of the use cases for it (imho). So you are probably not using the ajaxifier library (neither am I) and you are writing the ajax calls yourself. I'm afraid that means you have to implement a solution that fits your needs as well :-( You will have to determine what it means to 'go to the page before'. If it means 'going to the state before the last ajax call', then you are in for some work. I once tried to implement this (at esug 2012 in Gent actually) but I never finished it. Here is what I tried to do: Seaside ajax callbacks are changing the state of the current continuation without copying the state and snapping off a new continuation. If you want to be able to go back to the previous state before the ajax callback, an ajax callback should first copy the session state (just as is done in a full page request) before execution. The key for that state should go in the history api (as in [1]). When a request for that state comes in, the entire page should be re-rendered using the saved state. I think this should be able to get working using the abstractions available in Seaside and I would love to hack on that at ESUG this year. Unfortunately, promising anything before that is just not going to happen because of lack of time :-/ Johan [1] http://html5doctor.com/history-api/ On 19 May 2014, at 14:23, Sabine Knöfel <[hidden email]> wrote: > Hi, > > my application does much with ajax calls and because of this, my browser > history is nearly empty. > There are, indepently from pharo and seaside, several solutions for this > problem described in the web. > > But after looking around for a while I want to ask how did (or how would) > you solve this problem within pharo and seaside? > > I want that my users can click the back button and go to the "page before". > > Can I solve this with Seaside-REST? Which is the best way? > > Regards > Sabine > > > > > -- > View this message in context: http://forum.world.st/How-did-you-solve-the-ajax-back-browser-button-problem-tp4759490.html > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: How did you solve the ajax & back browser button problem?
|
|
Hi Paul and Johan, thank you for your answers! It took me some time to choose, understand and implement a solution, but I think, now I have it. As Paul assumes, I do not use the ajaxifier either, I write the callbacks by myself.
I integrated history.js [1]. I was just finishing it a few minutes before. If someone needs more informations about it please ask. Regards Sabine
On Mon, May 19, 2014 at 6:57 PM, Johan Brichau-2 [via Smalltalk] <[hidden email]> wrote:
|
Re: How did you solve the ajax & back browser button problem?
|
|
Sabine,
Could you post a small snippet of code of how you deal with the history state pushing? I can imagine how this could work using browser friendly URLs, but not when dealing with sessions (unless you're using cookie tracking for sessions).
Regards! Esteban A. Maringolo
2014-05-28 10:47 GMT-03:00 Sabine Knöfel <[hidden email]>:
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: How did you solve the ajax & back browser button problem?
|
|
Hi Esteban, each time, the user clicks at a back button relevant point, with History.pushstate(), [1] I add the name of the view as another parameter to the url, like this (last one):
When clicking at the back button [2], I extract the name of the view and can render [3] it. Please note that code is not yet cleaned up it is the current working status.
Also, currently I do re-render the whole page when clicking at the back button, I want to change this, later. This solution does only go back in the history of _views_ and does not load old objects. For my application, this is sufficient. Otherwise, you could add more information in the url variables, too and load the old objects, too.
[4] this is the js used (to be integrated in my Library) I am interested in your opinion! Regards Sabine [1] script add: (JSStream new nextPutAll: 'History.pushState';
arguments: (OrderedCollection with: aViewClass label
with: aViewClass label with: ('{1}&_v={2}'
format: {theUrlString. (aViewClass name)}));
yourself). [2] ^ ' var lock = false;
(function(window,undefined){ History.Adapter.bind(window,''statechange'',function(){
if (lock == false) { window.location = History.getState().url; } }); })(window);' [3] renderContentOn: | theView |
theView := self requestContext request queryFields at: '_v' ifAbsent: [ '' ]. theView := Smalltalk at: theView asSymbol ifAbsent: [ ].
[4] aHtmlRoot javascript url:'http://browserstate.github.io/history.js/scripts/bundled/html4+html5/jquery.history.js'. On Wed, May 28, 2014 at 4:05 PM, Esteban A. Maringolo [via Smalltalk] <[hidden email]> wrote:
|
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |