[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?
Philippe
> 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