[Seaside] ShoreComponents test cases -- worth doing?

[Pavel Krivanek]

>>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.
>
>Avi
>  
>
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.

target

"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:

target

^ target.

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 
Seaside components.

-- Pavel