[Seaside] call: vs rendered component

Philippe Marschall philippe.marschall at gmail.com
Mon Feb 26 08:32:00 UTC 2007

2007/2/26, Sean Malloy <smalloy at gmail.com>:
> I'm wondering what peoples thoughts are on the usage of call: vs
> assigning a Component instance to an ivar then rendering said
> component.
> example:
> I have an SMMain component which represents my ui layout.
> renderContentOn: renders the left nav, and the (current) component.
> SMMain>>children
>   ^Array with: component
> SMMain>>component: aComponent
>   component := aComponent.
> SMMain>>initialize
>   self component: SMHome new.

You haven't forgotten to register the component for backtracking, have you?


> SMMain>>renderContentOn: html
>   html div id: 'nav'; with: [ self renderNavOn: html ].
>   html div id: 'content'; with: [ html render: component ].
> SMMain>>renderNavOn: html
>   html anchor callback: [ self showHome ]; with: 'Stats'.
>   html anchor callback: [ self showStats ]; with: 'Stats'.
> SMMain>>showStats
>   self component: SMStats new.
> I'm hoping that how I'm setting the current component is fine. Because
> I notice most of the examples I've seen for Seaside use call: rather
> than just changing the ivar.
> For example, an alternative implementation to showStats:
> Main>>showStats
>   self component call: SMStats new.
> I'm just wondering if either one is as valid as the other.
> I guess my line of thinking is, you should use call: when you want to
> do something with the returned answer? Where as what I currently want,
> is just a placeholder where I can dynamically change the loaded
> component, and thus probably shouldn't be using call, because I'm not
> making use of #answer/#answer: (and could be creating lots of extra
> unnecessary continuations?)
> I searched the archives, but couldn't find any sort of guide like:
> "Only use call when you plan to make use of the answered object"
> Thoughts?
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

More information about the Seaside mailing list