[Seaside] ShoreComponents test cases -- worth doing?
squeak3 at continentalbrno.cz
Tue Jul 19 19:00:16 CEST 2005
>>IIt's really mainly "self check". Every component except real root should have a parent.
>I've been meaning to ask; what benefits does ShoreComponents get from
>this? Are they worth always having to specify a parent? Do we care
>about cases where the parent of a component might change? (For
>example, when you turn on the Profiler tool right now, it wraps itself
>around the previous root as its parent).
>Just curious, since I agree that a parent pointer can be useful but
>I've so far shied away from requiring it.
Parents are very important in ShoreComponents. There’s a set of
hierarchical methods which enables to build applications more easily.
You may look at structure of demo application. The base part of
resultant page is built from page content and side menu. The side menu
has subcomponent with anchors. Its actions look like "self target call:
something". #target is standard method which returns parent target or
self if no parent is available.
"Returns the receivers target"
^ (self parent respondsTo: #target)
ifTrue: [ self parent target ]
ifFalse: [ self ]
One of the parent components is ShoreDemo1Root which has two
subcomponents – panel and target. This component overrides standard
#target method to return target component:
The same mechanism is used for root etc. If any component wants to play
role of virtual root, it simply redefines #root method to return self.
No component overrides #realRoot method so this message returns real
root of the final application.
So we may build very general reusable components. Real root also may
contain next useful information like session cache.
Thanks parents we may also use components with nested forms (only the
most outer form is rendered - formRoot) and assign some attributes to
this forms (see ShoreRichEdit). Finally we still can use classical
More information about the Seaside