WAPresenter>>states

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?

Thanks,

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

2008/11/28 Eric Hochmeister <[hidden email]>:
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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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.

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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>> 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.

No, component decorations (and session filters in Seaside 2.9) are
backtracked automatically. They register themselves in #updateStates:,
but usually it is easier for end-user to just override #states.

> 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

There is no difference between returning an Array or an
OrderedCollection. You could even use a Set. Seaside just iterates
over the children using #do:.

Yes. When we say we want to backtrack an object, then we intent to
backtrack the contents of that object. This are by default the
instance variables of that object, not the object identity itself.

> 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?

You cannot only track the changes of the contents of an object, never
the object itself (it could be referenced from somewhere else).

Lukas

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

2008/11/28, Eric Hochmeister <[hidden email]>:
Right. If you use it like this, then there is no difference. What I
implicitly meant the following usage pattern:

You store your children in an OrderedCollection, you reference that
OrderedCollection in an instance variable of your component and you
modify that OrderedCollection but never the instance variable.

In this case you could just return and array (or any Collection) with
the OrderedCollection in #states. You can't return the
OrderedCollection itself because you want the OrderedCollection to be
backtracked.

Did this make sense or confuse only more?

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