#call: #answer / sessions

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

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

> > 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

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf
> Of Ramiro Diaz Trepat
> Sent: vendredi, 19. janvier 2007 03:28
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] #call: #answer / sessions
>
> > > 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
>
> If I create a subclass of WASession with the currentUser
> attribute, how do I inform Seaside to use it when I call self
> session? For it not to pass me a regular WASession Thank you
> very much for answering Ramón.
> By the way, the work you have been doing with onsmalltalk.com
> is great, particularly for noobs like me.
> Bye
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Found at http://localhost:8080/seaside/faq (SeasideFAQ package)
>
> Subclassing WASession
>
> It is sometimes necessary to subclass WASession. Typical situations for subclassing WASession.
>
> - Need to clean-up external resources when Seaside session expires (reimplement #unregistered)
> - Need to attach some data to the Seaside session using additional instance variables
> - Need to include additional behavior, statistics, monitoring (reimplement #responseForRequest:)
>
> Seaside applications are assigned their session class using the "config" application ("Session Class" field).
> It can also be set programmatically
>
>     app preferenceAt: #sessionClass put: MySession
>
>
>
>
> > -----Original Message-----
> > From: [hidden email]
> > [mailto:[hidden email]] On Behalf
> > Of Ramiro Diaz Trepat
> > Sent: vendredi, 19. janvier 2007 03:28
> > To: The Squeak Enterprise Aubergines Server - general discussion.
> > Subject: Re: [Seaside] #call: #answer / sessions
> >
> > > > 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
> >
> > If I create a subclass of WASession with the currentUser
> > attribute, how do I inform Seaside to use it when I call self
> > session? For it not to pass me a regular WASession Thank you
> > very much for answering Ramón.
> > By the way, the work you have been doing with onsmalltalk.com
> > is great, particularly for noobs like me.
> > Bye
> > _______________________________________________
> > 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
>

> >
> > 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.