OK to directly call (#renderContentOn: html) of sub-component ?

I read some time ago that a parent component should not directly call
#renderContentOn: on its children; instead it should do (html render:
child).

However, I've tried direct calls in a few places and it works OK; also makes
my interfaces more uniform, as parent may wants to pass some options into
the rendering of its child so often wants to use (child renderOn: html with:
options).

Is there a reason to avoid doing this?

Parent>>renderContentOn: html
    html div: 'Parent stuff'.
    child renderContentOn: html

Thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

No, not ok.

> I read some time ago that a parent component should not directly call
> #renderContentOn: on its children; instead it should do (html render:
> child).

Please, check the class-comment of WAComponent and the comment of
WAComponent>>#renderContentOn:.

If you do it anyway, decorations (e.g. #call:/#answer:) and child
components won't work. Callbacks will be owned and be executed in the
context of your parent. It is considered bad practice and will result
in unforeseeable problems.

Have a look at the self-senders of #renderContentOn: to see what you
miss when you call it directly. Alternatively step though #render:
with the debugger.

> However, I've tried direct calls in a few places and it works OK; also makes
> my interfaces more uniform, as parent may wants to pass some options into
> the rendering of its child so often wants to use (child renderOn: html with:
> options).

What you want is something pretty common, but then you should not
subclass WAComponent. Depending on whether you need state there are
two possibilities:

- Without state: create a new brush.

- With state: create a new class (subclass of Object) and implement
#renderOn: accordingly. Don't declare this object as a child, it is
not a component, but store it in some instance-variable (i guess this
is what you need).

Cheers,
Lukas

PS: Maybe you want to introduce yourself sometime? You ask a lot of
interesting questions and people are certainly interested to know who
you are and what you are doing ...

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

"Lukas Renggli" <[hidden email]> wrote in message
> Have a look at the self-senders of #renderContentOn: to see what you
> miss when you call it directly. Alternatively step though #render:
> with the debugger.

Thank you very much, I understand it now.

> - With state: create a new class (subclass of Object) and implement
> #renderOn: accordingly. Don't declare this object as a child, it is
> not a component, but store it in some instance-variable (i guess this
> is what you need).

I already do Menus like this, though my reason in that case was too many
components cluttering Seaside halos. In other cases perhaps I can do
something like:

Parent>>renderContentOn: html
    ...
    callback: [:r | self executeCallback.
                self basicRenderOn: r].

Parent>>executeCallBack
  model doSomething.
  self reconfigureChildrenInstVars.

> PS: Maybe you want to introduce yourself sometime? You ask a lot of
> interesting questions and people are certainly interested to know who
> you are and what you are doing ...

Of course ... I'm Sophie, working on a small niche web app (can't detail
much more yet), live in the US Southwest. I'm pretty new to Smalltalk (waded
in and out a couple of times in the past, but this is my first immersion). I
am almost completely new to Seaside and Scriptaculous (did a small
experiment once over a year ago, re-started just 2 months ago). I am amazed
at the framework, and at how quickly one can build without too much
experience. And I am nervous about how much I (probably) do not understand
yet.

Many thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> I already do Menus like this, though my reason in that case was too many
> components cluttering Seaside halos.

If you want to hide the halos of certain components you can override
#showHalo to return false.

> experience. And I am nervous about how much I (probably) do not understand
> yet.

I think you already know quite a lot.

Cheers,
Lukas

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

Sophie,

Forgive my ignorance, but wouldn't it be best and just plain easier to
instantiate and render your child components like so?

renderContentOn: html
  "Parent rendering.."
  self div
    id: 'parent';
    with: [ | child |
      "child rendering"
      child := ChildComponent new options: #('some' 'options').
      html render: child
    ]

Regards,
John.

www.pinesoft.co.uk

itsme213 wrote:

Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> renderContentOn: html
>   "Parent rendering.."
>   self div
>     id: 'parent';
>     with: [ | child |
>       "child rendering"
>       child := ChildComponent new options: #('some' 'options').
>       html render: child
>     ]

Given that this creates a new component on every rendering pass
(refresh), you will also loose the state that the child might want to
store (for example the selected option).

Cheers,
Lukas

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

It was a weak example, but you could also have:

initialize
  child := ChildComponent new.

renderContentOn: html
  html div
    id: 'parent';
    with: [ html render: (child options: #('some' 'options')) ]

where the options are of course variables and not static values.

Regards,
John.

www.pinesoft.co.uk

Lukas Renggli wrote:

Pinesoft Computers are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

"John Thornborrow" <[hidden email]> wrote in message
> It was a weak example, but you could also have:
>
> initialize
>  child := ChildComponent new.
>
> renderContentOn: html
>  html div
>    id: 'parent';
>    with: [ html render: (child options: #('some' 'options')) ]

Yes, doing this in #renderContentOn: seems cleaner than configuring child's
instVars in my callbacks. Sometimes my blind spots are bigger than my
seeing-spots :-)

Thanks - Sophie



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

itsme213 wrote: I too find your questions (Sophie) very instructive.  Your questions and
the answers have been very helpful. Just wanted to add my 2 cents.

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside