[Seaside] Let me see if I understand correctly...(more DB pool,
rleon at insario.com
Tue Feb 28 17:04:13 UTC 2006
Interesting, I've always found the missing application class an issue, I
just hacked around it by creating a custom config and tucking a
dictionary into the config, then added appAt: and appAt:put: to my
session class to write to that location. I think it's very common to
need session level, and application level state, maybe the community is
just small enough that it hasn't come up much. I use it to store css
layout info for components, then use the style method on the component
^(WACurrentSession value appAt: componentId)
This coupled with a little drag and drop allows form layout to be
customized per application instance. I wish I could just subclass an
App class, and set it up in configuration directly without needing to
use a custom config as an application store.
> -----Original Message-----
> From: seaside-bounces at lists.squeakfoundation.org
> [mailto:seaside-bounces at lists.squeakfoundation.org] On Behalf
> Of Julian Fitzell
> Sent: Monday, February 27, 2006 6:55 PM
> To: The Squeak Enterprise Aubergines Server - general discussion.
> Subject: Re: [Seaside] Let me see if I understand
> correctly...(more DB pool,application/session stuff).
> Just as a bit of history, there is a WAApplication class and
> there used to be UI for specifying a subclass to use for each
> entry point. But nobody ever used it. Everything was either
> session specific (session instance side) or specific to all
> applications that used one session subclass (class side of
> session) or shared across several "applications", in which
> case having other globals (whether they be singletons,
> classes, or whatever) made the most sense.
> I believe you can still technically subclass WAApplication
> and programatically create an entry point with something like:
> WADispatcher default registerEntryPoint:
> (MyApplicationSubclass new) at:
> but like I said, nobody seems to have found they need to do
> so and thus it's not really recommended (and certainly not
> tested) usage.
> Ramon Leon wrote:
> > You may want to check with Avi or Lucas, they'd know better, but I
> > think that's what the main class config setting is, a
> single instance
> > that acts as the application class. Keeping stuff here
> would seem to
> > be what you're looking for.
> >>-----Original Message-----
> >>From: seaside-bounces at lists.squeakfoundation.org
> >>[mailto:seaside-bounces at lists.squeakfoundation.org] On
> Behalf Of Rich
> >>Sent: Monday, February 27, 2006 4:31 AM
> >>To: The Squeak Enterprise Aubergines Server - general discussion.
> >>Subject: [Seaside] Let me see if I understand correctly...(more DB
> >>pool,application/session stuff).
> >>I can have my components use a session subclass that I've created.
> >>Each user gets their own session object (more or less, assuming of
> >>course they don't have multiple browsers open, etc.). So, if I want
> >>all the sessions to access an application-global resource (for
> >>example, a connection pool for a database), I would need to
> either use
> >>a global variable (which I'm not sure how to do in
> SmallTalk) or use a
> >>singleton class (which seems better than the global option,
> but still
> >>has some problems).
> >>Ideally I would like to subclass the application and have the
> >>application itself manage the global resource--but that
> does not seem
> >>to be a possibility within the seaside framework.
> >>Am I missing something, or thinking about this the wrong way?
> >>Thanks again, all your help has been incredibly useful up to this
> >>Seaside mailing list
> >>Seaside at lists.squeakfoundation.org
> > _______________________________________________
> > Seaside mailing list
> > Seaside at lists.squeakfoundation.org
> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside