State shared between components

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

State shared between components

Holger Kleinsorgen-4
Hello,

while implementing #states for some components, I encountered an oddity,
and I'm not sure if me or Seaside is missing something. Some components
share a common object containing context information (roughly comparable
with the Refactoring Browser's navigator state). And since the
components don't know of each other, they happily include the context
object when asked for #states.

However, #register: is implemented the following way:

   WASnapshot>>register: anObject
     anObject ifNotNil: [ self at: anObject put: anObject snapshotCopy ]

so the snapshot machinery will overwrite the previous snapshot of the
shared context again and again.

Since the application contains a lot of components, and the context
object is a bit heavy, I've tweaked #register: the following way:

   WASnapshot>>register: anObject
      anObject notNil ifTrue: [
         self at: anObject ifAbsentPut: [ anObject snapshotCopy ]
     ].

is this a valid patch? Or will I run into troubles somewhere else?
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: State shared between components

Lukas Renggli
>  Since the application contains a lot of components, and the context
>  object is a bit heavy, I've tweaked #register: the following way:
>
>    WASnapshot>>register: anObject
>       anObject notNil ifTrue: [
>          self at: anObject ifAbsentPut: [ anObject snapshotCopy ]
>      ].
>
>  is this a valid patch? Or will I run into troubles somewhere else?

It looks fine to me.

You scenario looks plausible. When implementing the #states mechanism
I didn't think that anybody would try to register the same object
multiple times. In Pier for example, this is only the root component
(the one that also instantiates the context with the first request)
that registers it for backtracking. If you have a custom session class
another solution would be to let the session register the context for
backtracking.

Still, it might make sense to add your patch to Seaside 2.9? I don't
know if this is generally useful, as I have never seen such a
situation before.

Lukas

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