[Seaside] #call: #answer / sessions

[Ramon Leon]

> I have a couple of basic questions
> 
> 1)
> Is it OK to #call components that never #answer ?  For 
> instance if you have a page with a menu that #calls 
> components for each of its menu items, and the user may do 
> this again before the component #answer.
> I believe this is the case, for instance, on the Sushi Store, 
> where a user can be adding sushi to the cart and click on the 
> Browse link on the menu bar, which will #call the browsing 
> component again, before answering.
> The question is: Will this generate a memory leak ?  Will all 
> those compoenents add up ? Or is this the proper way to do it?

Yes, it's ok.  It might help if you think of #call: as simply display this
component instead of this other component.  A component doesn't have to
answer, nor are you always interested in its answer.

self call: Component new

Replaces self with a new component, whereas if you simply wanted to render a
component without replacing it in the UI, you'd

html render: self someComponent 

In the render method of the outer component.

> 
> I'm asking because I am developing my first real basic, but 
> comertial application in Seaside, and I have not cached up 
> with it real well yet.
> I have a very simple page, with a header, a navigation bar 
> and a main area, very similar to the Sushi Store.  But I have 
> a WAComponent for each of those (header, navbar, etc.), 
> placed an the page using divs.
> The component of the navication bar, simply shows some 
> options that when clicked, #call the proper component to be 
> displayed on the main area.  What I have to do for the 
> component to be displayed on the main area is calling the 
> #call method from the previous component that is on the main 
> area, otherwise this newly selected component will be 
> displayed on the navigation bar DIV.
> Is this the proper way to build a basic web app that displays 
> a specific component for whatever is clicked on the navigation bar?

Yes, this is correct.  I like to have a currentComponent in a layout like
this, and simply have the menus say 

currentComponent call: SomeNewComponent new.

>From the outer container, which acts like a mediator controlling what item
is displayed.  Expect the component to get garbage collected after it's no
longer displayed since you're not holding onto a reference.  If you want to
reuse existing components rather than creating them on each invocation, you
could do...

currentComponent call: (self componentFor: SomeNewComponent)

componentFor: aComponent
  ^components at: aComponent ifAbsentPut:[aComponent new]

And use the components class as a key into a dictionary so you can reuse the
same instance each time they click that menu item.  Since you're holding a
reference to it, it won't be gc'd just because it's not displayed and you
can use the original instance over and over, meaning it'll maintain any
state it previously held, a sometimes very useful and unexpected thing in a
web application.

> 2)
> When you develop a login process, like the one in Ramon's 
> blog.  Where is it proper to store the user that is logged 
> on? Is this supposed to be stored somewhere in the WASession?

Yes, a custom session class is a good place for this, so you can have access
to it from every component with a simple..

self session currentUser

Also common is

self session database

Ramon Leon
http://onsmalltalk.com