[Seaside] ShoreComponents test cases -- worth doing?

Philippe Marschall philippe.marschall at gmail.com
Sat Jul 23 13:55:19 CEST 2005

I must say I'm against including the parent link and using the parent
link for accessing and mutating information.

We have an application where we implemented something like that (it's
actually called target). Sometimes this is the parent component,
sometimes not. In general it is `the right component' . We use this
for passing information to client components and answering. The
problem is that this is really messy, because you do not know what
exactly the parent is. Also it's bad for reusability because you don't
really know, what the parent of a component has to look like.

The solution I like more for this kind of stuff are dynamic variables.
They also have two other advantages.
- they have names which provide information about their use, not just `parent'
- they are searchable via class refs

Their disadvantage is that you need (or should) create a class for for
each variable. But in all the applications we did, we only saw very
rarely use such variables. So this shouldn't be a problem.

See the attached mcz file who updating of the header title can be done
from a counter without the parent link, just with dynamic variables.
(ShoreComponents is a depency because it's used for styles and images)

So I'd rather like seaside to have support for dynamic variables that
can be used while processing callbacks and rendering

something like

    ^Array with: WACurrentSubtitleHolder -> self subtitleHolder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WAComponents-pmm.1.mcz
Type: application/octet-stream
Size: 2962 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/seaside/attachments/20050723/ced5d46e/WAComponents-pmm.1.obj

More information about the Seaside mailing list