call: vs rendered component

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.

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

2007/2/26, Sean Malloy <[hidden email]>:
You haven't forgotten to register the component for backtracking, have you?

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

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


Well I probably have forgotten to, however my question wasn't about
back tracking. I was actually more interested in knowing which of
those two styles is the preferred style, and in what situations?

I noticed a thread from a couple of days ago by Avi regarding features
people may or may not use - He mentions that dabble uses less call:'s
than people might think, and more just plain rendering of inline
components. So it got me thinking, do people tend to sway one way or
the other, or mix and match depending on the situation (and please
cite an example of where you would use call: over just rendering the
component inline)

Regards,

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

On 2/25/07, Sean Malloy <[hidden email]> wrote:

> 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'd say it comes down to roughly the distinction between modal and
modeless for dialog boxes.  Is the new component something the user
will deal with, and then return to where they are now, or one step in
a multistep process? If so, use #call:.  Is it pure modeless
navigation, where they're just changing the page they're looking at?
If so, your strategy is IMO the right one.  In your case I'd say
you're doing the right thing.

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

The following code allows the web client to download comma separated  
data.

html anchor
     document: (self csvData asMIMEDocumentType: 'text/csv')
     mimeType: 'text/csv'
     fileName: 'ctaexport-' , Date today yyyymmdd , '-' , Time now  
hhmm24 , '.csv';
     text: 'Export (csv)'.

My problem is that the MIME document is created at render time, but  
the data I want sent is dependent upon the fields on the form. Anyone  
know of a convenient way to make the document be created after the  
link is clicked?

Thanks in advance, Brian.

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

> My problem is that the MIME document is created at render time, but
> the data I want sent is dependent upon the fields on the form. Anyone
> know of a convenient way to make the document be created after the
> link is clicked?

Yes, this is a common problem. One solution is to create an anchor and redirect:

html anchor
    callback: [ self session returnResponse: (WAResponse document:
anObject mimeType: mimeString fileName: fileString) ];
    with: 'Export'

Cheers,
Lukas

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

Hadn't heard of #returnResponse: before, but your solution is exactly  
what I needed. Thanks much, Brian.


On Feb 26, 2007, at 11:22 PM, Lukas Renggli wrote:

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