[Seaside] #render: or #call: components.

[Edward Stow]

On Mon, Apr 28, 2008 at 8:07 PM, John Thornborrow <john at pinesoft.co.uk> wrote:
> Hi,
>
>  #call: should only be used in a callback, or when using a WATask subclass.
> (The latter leaves you no option anyway, as WATasks cannot/do not render)
>
>  If you want multiple components rendered on the same page, you must use
> #render:, if you want to pass control of the session to another component,
> use #call: within a callback.

I was aware of the limitations on using #render: and #call: - perhaps
my elaboration below will better illustrate my question.
>
>  It is also worth noting the #onAnswer: message, this allows you to render
> multiple components and ensure all will do specific action upon answering.

So .. adding the #onAnswer is the equivalent of using #call: in the
rendering process?

Elaboration:

1. Displaying sub components with #call:
-----------------------
ParentComponent>>renderContentOn: html

<render heading information >
html render: ChildComponentA new
<render footer informaton >

ChildComponentA>>renderContentOn: html

html anchor
    callback: [ self call: ChildComponentB new  ];
    with: 'Show child component B'

ChildComponentB>>renderContentOn: html

html anchor
    callback: [ self call: ChildComponentA new  ];
    with: 'Show child component A'

Or  2. Display with render: in sub components
---------------------------------------
ParentComponent>>renderContentOn: html

   html render: self bodyComponent.

#bodyComponent returns either a ChildComponentA or ChildComponentB instance.

ChildComponentA>>renderContentOn: html

html anchor
    callback: [ self showChildComponentB  ];
    with: 'Show child component B'

ChildComponentB>>renderContentOn: html

html anchor
    callback: [ self showChildComponentA  ];
    with: 'Show child component A'

The #showComponentX methods will indirectly communicate  with the
Parent via announcements, or perhaps via globally accessible object
like the session and set the bodyComponent in the parent ready for the
next rendering.

Both approaches result in the page rendered with the same content.
Are their any compelling reasons to use one over the other?

-- 

Edward Stow