Re-render component on back button

I'm developing a shopping cart and wondering if there's any way to show its size consistently even after pressing the back button.

I think I would need to force a re-render, but since I'm not sure what the browsers actually request on back button presses I'm at a loss how to configure this, if possible.

When I open the developer tools network tab in chrome and press the back button, the behaviour is different than normally, ie. after I added an item and it shows '1 article' and I press back, then the component is properly re-rendered and still shows '1 article' even on the previous page. So chrome requests are probably
different..

Is it possible to force this behaviour in the normal browser state?

greetings,
        Lo_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Is it possible to force this behaviour in the normal browser state?

BTW, what is the equivalent of isolate: in seaside 3.x? How do I invalidate previous pages and redirect the user to the last valid one? There doesn't seem to be any reference anywhere to what happened to isolate: !

Lo_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lorenz,

Isolate: is gone. There is a big report about this. I am at the airport right now, so sorry for not providing a link.

Joachim

Am 01.12.2013 um 17:38 schrieb Lorenz Köhl <[hidden email]>:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Lorenz,

Can you give us a little more context? Does the rendered state of the shopping cart correspond to its actual contents?

In vanilla seaside, this should be true. The conponent should be re- rendered when you press the back button. What you are seeing might be "desired" behavior. Back in 2005, we all went nuts about continuations and the fact that the back button finally works right in seaside ;-) our definition of consistency was somewhat different from the rest of the world's...

So I suggest to try the following:

1. Put a halt or breakpoint into the component's rendercontentOn: to see if it re-renders

2, render an inspect link into the component to see if what the component shows is what the cart contains. All you need is an anchor with a callback like this: callback: [myCart inspect]

The basic question IMO is what your definition of "consistent" is and whether you expect the right thing to happen.

The chrome differences In behavior should be addressed right next after that.

Joachim

Am 01.12.2013 um 16:34 schrieb Lorenz Köhl <[hidden email]>:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sorry, I typed Bug report, but my phone thought I mean Big report... I'm so eighties when using my smartphone ;-)

Am 02.12.2013 um 07:27 schrieb Joachim Tuchel <[hidden email]>:
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Hi Lorenz,

I am not sure what you are asking, so I will give you 2 answers:

Answer 1) Session state.
Seaside has tools for rendering the same page or a different page on a back button. There is the so-called "session" state. This state depends on where you are. Depending on how you implement children and states, components are part of this session state. So if you store your shopping cart in your session state, then going back, would also roll back the shopping cart. If you want it to persist, then you have to store it somewhere else. For instance, you could make a shopping cart cache belonging to the user. And if it is a guest user, than you make some temp user, that is removed after a certain time.

Answer 2) Browser cache.
Caching is possible on the browser side, and on proxy servers. In the header information you can supply information wether a browser or proxy is supposed to cache a page, and for how long, or if they are supposed to reload a page always. I believe the default is that it is not specified in seaside, and thus browser dependent. You have to look up how to set this, but it should not be too hard. Also in production you probably have a web server between your seaside and the net, and I usually configure it here.

Diego

On Dec 1, 2013, at 4:34 PM, Lorenz Köhl wrote:

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I did a little poking around with WACounter (early seaside version 3) and..

When hitting the back button(Chrome), the screen updates correctly, but does not re-render, suggesting caching. So I requested no-caching:

renderContentOn: html

    self requestContext response doNotCache.
    html heading: Time now asString.
    html heading: count.
    html anchor
        callback: [ self increase ];
        with: '++'.
    html space.
    html anchor
        callback: [ self decrease ];
        with: '--'.
   
And still no re-render. Google found this:

http://blog.55minutes.com/2011/10/how-to-defeat-the-browser-back-button-cache/

Changing:

WAResponse>>doNotCache
    "Configure the receiver to not be cached at all."
   
    self headerAt: 'Pragma' put: 'no-cache'. "Proxies"
    self headerAt: 'Expires' putDate: self doNotCacheExpiryDate. "HTTP 1.0"
    self headerAt: 'Cache-Control' put: 'no-cache, max-age=0, must-revalidate, no-store'. "HTTP 1.1"

and now it re-renders on a back button. HTH

Cheers,
Bob

I'm developing a shopping cart and wondering if there's any way to show its size consistently even after pressing the back button.

I think I would need to force a re-render, but since I'm not sure what the browsers actually request on back button presses I'm at a loss how to configure this, if possible.

When I open the developer tools network tab in chrome and press the back button, the behaviour is different than normally, ie. after I added an item and it shows '1 article' and I press back, then the component is properly re-rendered and still shows '1 article' even on the previous page. So chrome requests are probably
different..

Is it possible to force this behaviour in the normal browser state?

greetings,
	Lo_______________________________________________
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

Folks,

thanks for the suggestions and examples!

I have now configured apache to act as reverse proxy between Pharo and the browser.
It rewrites the Cache-control header to Bob's and indeed, when all four arguments are provided Chrome is convinced to not check its cache (I tested and hope it stays that way).

Seaside 3.1, which I run, has this in #doNotCache

        "Configure the receiver to not be cached at all."
        self headerAt: 'Pragma' put: 'no-cache'. "Proxies"
        self headerAt: 'Expires' putDate: self doNotCacheExpiryDate. "HTTP 1.0"
        self headerAt: 'Cache-Control' put: 'no-cache, must-revalidate' "HTTP 1.1"

As you can see max-age and no-store are missing, so the method doesn't do as much as it could!
I filed an issue:
        https://code.google.com/p/seaside/issues/detail?id=772

greetings,
        Lo_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Dec 2, 2013, at 9:33 AM, Diego Lont <[hidden email]> wrote:
>  If you want it to persist, then you have to store it somewhere else. For instance, you could make a shopping cart cache belonging to the user. And if it is a guest user, than you make some temp user, that is removed after a certain time.

Where to put user and view state can become quite confusing indeed. I got sidetracked building this user abstraction, but have now settled on application specific WASession classes which search for an agent/user and create it if  necessary. An agent has a #state: method where index the models by class, eg.

        agent state: MyShoppingCartModel

and the model is lazily initialized. In components I can thus do:

        (self session agent state: MyShoppingCartModel) add: self product


The #state: method also injects the agent's announcer (each agent announces its activites) on each model.
A model then announces a change, eg. MyShopAddedItemToCardEvent.

The agents events are also re-announced (think 'retweeted') in the session so that components may react.

        MySession >>#initialize
                agent announcer on: Announcement do: [ :ann | self announcer announce: ann ].

It's a bit involved (two announcers, models must accept announcers), however I think this way the state is nicely decoupled from seaside specifics, so writing a morphic gui that monitors the shop should be easy.

What do you folks think, over-engineered? How did you solve this?

By using announcements for everything on the page you get a built-in analytics engine with the little more effort to store them in an event DB. Maybe this could be used for automated split-testing…

Has anyone here done split tests with seaside?


> Also in production you probably have a web server between your seaside and the net, and I usually configure it here.

Do you rewrite all caching for seaside interaction? Or is there scheme as to what should be cached? (eg. /files should be served with caching). But in general, all requests with callbacks involved shouldn't be cached, right?

greetings,

        Lo

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside