[Seaside] WAPresenter>>states

[Eric Hochmeister]

Philippe,

> Only the things returned by #states are backtracked.

So by default, nothing is backtracked on a new component.  Since
#states by default returns an empty collection.

> If your children
> change over time, backtracking needs to happen somehow which means you
> have to implement #states at some place. Where and how depends very
> much of your situation. If you store all your children in and
> OrderedCollection then only backtracking those will suffice. However
> if your #children looks something like:
>
> children
>    ^Array with: firstComponen with: secondComponent
>
> then you probably need to backtrack the component itself.

Sorry, just to try and figure out the difference between
OrderedCollection and Array above, I'm guessing in your above
paragraph you're describing the instance where components are stored
within an OrderedCollection on an instance variable which is returned
by "children" rather than having children generate a new instance of a
Collection containing components everytime?  Is this correct? (ie.
children ^myChildren, where myChildren is an OrderedCollection
containing the components)

If not, I'm not sure I see the difference in children returning an
Array or OrderedCollection.
children
^ Array with:a with:b
and
children
^ OrderedCollection with:a with:b

> Sometimes it's trick to find the right object to backtrack. For
> example the counter does not backtrack the count integer because that
> doesn't change. It backtracks the counter because it is him who
> changes. When in doubt backtrack the component. That will use more
> memory but work.

"For example the counter does not backtrack the count integer because
that doesn't change."

This is because the object which the count instance variable is
referring to is modified (and its on WACounter, so the WACounter
instance is changing) rather than the value which count is referring
to, since it's not changing, just being replaced.  This is what you
mean?

But if I had an instance variable (x) referring to another object (y)
and one of its instance variables were modified, I could track the
object being referenced directly (y), since the object (y) would not
change, only its values.  I could then include just y in #states?

Thanks again,

Eric