For the FAQ: Making the back button work

On Dec 30, 2007 2:39 PM, Philippe Marschall
<[hidden email]> wrote:

> [...] if the value
> of #children changes over time you need to use backtracking to make
> sure the back button works correctly.

What do I need to do to make sure the back button works correctly in
my application?

I'm not asking about an actual application; this is a question for the
FAQ. But I am asking for more explication; exactly how does one do
this? It's not clear to me what should happen, for example, if one of
the items returned by #children is no longer intended to be rendered;
does it need to stay in #children in case the back button might cause
it to be rendered once again?

In particular, does handling the back button depend upon the
application? The page on "Maintaining State" in the documentation
section on www.seaside.st gives a (slightly broken) example, but one
which contrasts with WACounter's way, thereby implying that there is
more than one way for an application to handle the back button. What
different ways are useful and supported?

Cheers!

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

2007/12/31, Tom Phoenix <[hidden email]>:
You need to tell Seaside which objects need to be backtracked and let
Seaside the backtracking for you. Which objects need to be backtracked
depends on your application. How you tell Seaside to backtrack an
object depends on your Seaside version. In <= 2.7 you send
#registerObjectForBacktracking: to your session, in 2.8 you return
#states in your component.

to go back to the example of Randal:

 initialize
   super initialize.
   body := self body1. "set up the initial component"

 children
   ^ Array with: body. "don't forget this!"

 renderContentOn: html
   ...
   html anchor callback: [body := self body1]; with: 'first body'.
   html anchor callback: [body := self body2]; with: 'second body'.
   ...
   html render: body. "render the current body"
   ...

In this case you would have to implement

states
    ^Array with: self

Because the contents of self (the content of the body instance
variable) changes ower time and needs to be backtracked. Else you
could use the back button to go to a state where a different body was
displayed.

in Seaside <= 2.7 you would do:

 initialize
   super initialize.
   body := self body1. "set up the initial component"
   self session registerObjectForBacktracking: self

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

On Dec 31, 2007 3:08 AM, Philippe Marschall
<[hidden email]> wrote:

> states
>     ^Array with: self
>
> Because the contents of self (the content of the body instance
> variable) changes ower time and needs to be backtracked. Else you
> could use the back button to go to a state where a different body was
> displayed.

Thanks; this is very helpful.

Unless I'm missing something, there is nothing preventing a web user
from using a cached page to follow a link or (re)submit a form that is
no longer valid in the current context. When that happens, unless the
old links have expired from Seaside's cache, the callbacks fire. If I
want my application to recognize when the user has submitted something
that's no longer valid, I have to put a check into each callback. Is
that right?

For example, suppose my application implements a card game, and the
user chooses to draw a new card. If I want the application to prevent
them from going back and choosing a different game action, since
they've now seen the new card, I need to check at each link (i.e. game
action choice) that the game state hasn't changed to disallow that
choice.

WAComponent>>isolate: seems related, but I can't find documentation on
how to use it. Is that what I'm looking for?

Thanks!

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

> WAComponent>>isolate: seems related, but I can't find documentation on
> how to use it. Is that what I'm looking for?

Yes, #isolate: is what you are looking for.

For some documentation see "6.2 Transactions" in
http://www.iam.unibe.ch/~scg/Archive/Papers/Duca04eSeaside.pdf.

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Dec 31, 2007 12:03 PM, Lukas Renggli <[hidden email]> wrote:
> > WAComponent>>isolate: seems related, but I can't find documentation on
> > how to use it. Is that what I'm looking for?
>
> Yes, #isolate: is what you are looking for.

I've put together a simple example application to show how #isolate:
can be used to keep the user from using the browser's back button and
following an invalid link. It's on SqueakSource if I've done this
right:

    http://www.squeaksource.com/fgg.html

After installing, it should show up in the Functional Seaside Test
Suite, although it can also be configured to stand-alone.

Enjoy!

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