[Seaside-dev] Issue with #removeDecoration:

[Lukas Renggli]

Hi John,

>  I noticed Seaside2.8a1-lr.559 has the comment "fixed the backtracking bug
> (only an ugly solution)" and was wondering if this is related to the bug
> below, and also I was wondering what the work around you mentioned is?

we added (a slightly simplified version) of your test case to the
functional test-suite of Seaside (WADecorationTask, WADecorationTest).
The commit comment should have stated that I fixed the test, not the
actual cause of the problem.

I tried to explain the problem in my blog (second paragraph):

	http://www.lukas-renggli.ch/blog/seaside-sprint-may-08

Older versions of Seaside did not show that problem, because as soon
as you registered something for backtracking it was backtracked
forever. That was one of the reasons why Seaside was so memory hungry
in versions prior to 2.8. Backtracking only visible components leads
to strange side effects in rare cases though.

There are essentially 3 possibilities solving your problem:

1. We discussed with Avi and he argues that it is good practice to
create a new component on every call. Instantiating new components
might not be desired in your case, but it is certainly what is done in
most situations. In fact I checked all my Seaside code-base and didn't
find a single place where this "rule" was violated.

2. Make sure that state-snapshots are also takes from invisible
components (that's how I fixed the test-case).

WADecorationTask>>updateStates: aSnapshot
	super updateStates: aSnapshot.
	component1 visiblePresentersDo: [ :each | each updateStates: aSnapshot ].
	component2 visiblePresentersDo: [ :each | each updateStates: aSnapshot ]

3. Or even simpler, just register the two components as children of the task:

WADecorationTask>>children
	^ Array with: component1 with: component2

My blog entry sounds a bit too optimistic. The issue is very likely
not easily fixable in a generic manner and without vasting vast
amounts of memory. Unless somebody from the community has a flash of
genius we probably won't be able to change anything there.

Cheers,
Lukas

-- 
Lukas Renggli
http://www.lukas-renggli.ch