[Seaside] 2.1 preview

[Alain Fischer]

Hi Avi,

What are the prerequisite for filling in Seaside 2.1 because I have a:

MessageNotUnderstood:=20
=
subclass:instanceVariableNames:stateVariableNames:classVariableNames:poolD=
ictionaries:
category:

while filing in:

RewindableObject
	subclass: #WATransactionStack
	instanceVariableNames: ''
	stateVariableNames: 'currentTransaction '
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Seaside/Kernel-Transactions'

Alain



Le Mardi 17 d=E9cembre 2002, =E0 09:40 , Avi Bryant a =E9crit :

> Hi all,
>
> I've put an early release of Seaside 2.1 up at
> http://beta4.com/seaside2/Seaside2.10.st.gz .
>
> The main change in this release is that the old ManagedObject/IVAP=20
> method
> of instrumenting instance variable reads and writes is no longer used.
> Instead, it introduces an explicit stateTree instance variable which =
is
> used by components to read and write state that needs to rewind and
> fork for the back button.
>
> Although you could directly use stateTree #at: and #at:put:, =
subclasses=20
> of
> WAComponent now also have an extra line in their class definition =
which
> allows you to declare stateVariableNames.  Accessors which go through=20=

> the
> stateTree will be generated for each of these names.  For example,
>
>   WAComponent subclass: #WACounter
> 	instanceVariableNames: ''
> 	stateVariableNames: 'count '
> 	classVariableNames: ''
> 	poolDictionaries: ''
> 	category: 'Seaside/Examples-Basic'
>
> generates
>
>   count
> 	^stateTree at: #count
>
>   count: anObject
> 	stateTree at: #count put: anObject
>
>
> This change does raise the question of when it's appropiate to use
> stateVars instead of instVars.  When in doubt, it never hurts to make
> something a state variable (except for increased memory usage...).  As =
a
> rule of thumb, however, if you ever change the value of an instance
> variable *after* the component is first created and initialized, then =
it
> should probably be a stateVar.  Going through my own code, I found it
> interesting how few instance variables this applied to... I'm hopeful=20=

> that
> making this distinction more explicit will lead to a better=20
> understanding
> of mutation patterns in general.
>
> I'd appreciate it if people tried this out and let me know how they=20
> found
> the new approach.
>
> Cheers,
> Avi
>
>
>
>
> _______________________________________________
> Seaside mailing list
> Seaside@lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>