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 |
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 |
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, _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
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 |
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 |
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 |
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 |
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 |
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 |
Free forum by Nabble | Edit this page |