Help with understanding how #call: works

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Help with understanding how #call: works

squeakman
Greetings,

I have two components A and B and I have the following code in A.

renderContentOn: html
        self call: B new.

What I was expecting is that B would be rendered.

(I suspect that there would be problems when B answers but for this
experiment, this was not my concern yet.)

My question is: Why doesn't B get rendered?  All I get is a blank screen.

And, I know this a contrived example and is probably not something one
would normally do.  I just want to understand why this does not work.

Many Thanks,
Frank

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Help with understanding how #call: works

David Mitchell-10
Don't call in a render.

When you see call: in the renderContentOn:, it is inside a block,
which is invoked later (usually on a click). See

http://www.shaffer-consulting.com/david/Seaside/CallAnswer/index.html

Quoting:

Don't call: from renderContentOn:
One of the most common mistakes of first-time Seaside users is to try
to call: a component from another components rendering method,
renderContentOn:. The rendering method is just for that, rendering. It
should display the state of the current component just as it is. It is
the job of callbacks to change state, call other components etc. There
is never a reason for a typical Seaside user to invoke call: during
rendering. If you want to render one component inside another one read
the chapter on Embedding components.

On Fri, Feb 22, 2008 at 9:00 AM, Squeaker <[hidden email]> wrote:

> Greetings,
>
>  I have two components A and B and I have the following code in A.
>
>  renderContentOn: html
>         self call: B new.
>
>  What I was expecting is that B would be rendered.
>
>  (I suspect that there would be problems when B answers but for this
>  experiment, this was not my concern yet.)
>
>  My question is: Why doesn't B get rendered?  All I get is a blank screen.
>
>  And, I know this a contrived example and is probably not something one
>  would normally do.  I just want to understand why this does not work.
>
>  Many Thanks,
>  Frank
>
>  _______________________________________________
>  seaside mailing list
>  [hidden email]
>  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Help with understanding how #call: works

Diogenes Moreira
In reply to this post by squeakman
Hi,

In Simple words..

When you use #call, you send the control to B object and  Object A waits for B object answer.

I can guess  this problem happend  becouse  B Object don't receive any canvas or context. renderON: method do this.

If you want render the B Object, the correct Form is:

#renderContentOn: html
      "child is a instance variable"
     self child:=B new.
     html render: self child.


And not forget children method.

#children
       ^ self child.

Is very common use #call method in callbacks..

Regards

PD: sorry for my english.
On Fri, Feb 22, 2008 at 1:00 PM, Squeaker <[hidden email]> wrote:
Greetings,

I have two components A and B and I have the following code in A.

renderContentOn: html
       self call: B new.

What I was expecting is that B would be rendered.

(I suspect that there would be problems when B answers but for this
experiment, this was not my concern yet.)

My question is: Why doesn't B get rendered?  All I get is a blank screen.

And, I know this a contrived example and is probably not something one
would normally do.  I just want to understand why this does not work.

Many Thanks,
Frank

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


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Help with understanding how #call: works

squeakman
In reply to this post by David Mitchell-10
David Mitchell wrote:
> Don't call in a render.
>
> When you see call: in the renderContentOn:, it is inside a block,
> which is invoked later (usually on a click). See
>
> http://www.shaffer-consulting.com/david/Seaside/CallAnswer/index.html
>
Thanks David.

I have a follow up question.

I am assuming if I do a

      self call: componentX

that I do not have to add componentX to the calling component's list of
children. Is this true?

My experiments seem to confirm my assumption but is this the correct way
to be doing things?

Thanks for the help,
Frank

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Help with understanding how #call: works

Malte Zacharias
Hello David,

> I have a follow up question.
> I am assuming if I do a
>
>      self call: componentX
>
> that I do not have to add componentX to the calling component's list of
> children. Is this true?
Yep, that's how it's done. You only need to include those components in
children which are going to be rendered the next time the component
implementing children is rendered. (E.g. if you have html render:
aComponent within the rendering code you need to include it) A call
actually replaces the component that calls another with the called
component (until the called component answers).

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Help with understanding how #call: works

JeffreyStraszheim
Malte Zacharias wrote:
> Yep, that's how it's done. You only need to include those components
> in children which are going to be rendered the next time the component
> implementing children is rendered. (E.g. if you have html render:
> aComponent within the rendering code you need to include it) A call
> actually replaces the component that calls another with the called
> component (until the called component answers).
In this case, would you have to included the called element in the
parent's children list?


--
Jeffrey Straszheim
http://straszheim.50megs.com

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Help with understanding how #call: works

Malte Zacharias
Hey Jeffrey,

>> Yep, that's how it's done. You only need to include those components
>> in children which are going to be rendered the next time the component
>> implementing children is rendered. (E.g. if you have html render:
>> aComponent within the rendering code you need to include it) A call
>> actually replaces the component that calls another with the called
>> component (until the called component answers).
> In this case, would you have to included the called element in the
> parent's children list?

In which of the two cases ;)?
1.If component a calls b: No
  a>>children
        ^#()

  Happens when you call a component within a callback Block usually or
  within a Task, e.g.:
  a>>renderContentOn: html
  html anchor callback: [ self call: b ]; with: 'Call b'.

2.If component a causes b to be *rendered* within a: Yes.
  a>>children
        ^#( b )

This happens when you display b like this:
  a>>renderContentOn: html
  html heading level:1; with: 'Blablabla'.
  html render: b.

I hope this clears it up a bit..
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Reply | Threaded
Open this post in threaded view
|

Re: Re: Help with understanding how #call: works

JeffreyStraszheim
Malte Zacharias wrote:

<snipage>
> I hope this clears it up a bit..
>

Not really.  What I'm looking for is this, if component A includes
component B, but inside of B, it calls component C, what happens?

I assume C renders *in place* of B and the rest of A works as it did
before?  Is this correct?

If so, does A have to include C in its children as well as B?

It is possible I totally don't understand this stuff.

--
Jeffrey Straszheim
http://straszheim.50megs.com

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

Reply | Threaded
Open this post in threaded view
|

Re: Re: Help with understanding how #call: works

Stefan Schmiedl
On Sun, 24 Feb 2008 23:56:46 -0500
Jeffrey Straszheim <[hidden email]> wrote:

> What I'm looking for is this, if component A includes
> component B, but inside of B, it calls component C, what happens?

Rendering A triggers rendering of B, so B should be in A's children.
A does not (should not need to) know anything about what's happening
inside B.

> I assume C renders *in place* of B and the rest of A works as it did
> before?  Is this correct?

yes, the output might be the same as if A had rendered C instead of B,
but the path by which you got there is different.

>
> If so, does A have to include C in its children as well as B?

No, because the replacement is B's 'local' or 'private' decision.
If A had to know this, it would break the component
encapsulation paradigm.

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