[Seaside] WAPresenter>>states

[Philippe Marschall]

2008/11/28 Eric Hochmeister <erichochmeister at gmail.com>:
> Hi,
>
> I was just wondering if I could get a clarification or brief
> explanation on #states and its uses (when to use, why).
>
> >From my understanding, it seems that #states should be used when the
> return value of #children is dynamic over the life-span of the
> component.
>
> #states should return the same thing as #children in this case (a
> collection of the child components)?
>
> If the child components do not change in the life-span of the
> component, then there is no need to implement #states on the
> component.
>
> #states enables backtracking to work correctly on the components which
> have been changed within the life-span of the component. (/enables
> seaside's ability to track the dynamic components such that
> backtracking will work correctly)
>
> Is this correct?  Is that all I need to know, or am I missing something?

Only the things returned by #states are backtracked. 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.

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.

Cheers
Philippe