[Seaside] Let me see if I understand correctly...(more DB pool,
julian at beta4.com
Tue Feb 28 19:52:15 UTC 2006
Well, as Avi and I said, you *can* just subclass App and set it up in
But while I have subclasses Application classes frequently in other
environments, it has never proved interesting in my seaside development
work. Not sure exactly what the difference in paradigm is.
I think what we found is that we *always* have customized session
classes anyway and they are usually customized to the point that they
only make much sense with one application (or at least one group of
applications) anyway. And since we already had a class customized for
our application and the class-side therefor provides a convenient
per-application code location, there was no need to complicate matters
by adding another custom subclass.
Also, we rarley had code that was per-entry-point (an application is an
entry point) anyway. It was either common functionality shared across
arbitrary entry points, in which case it wanted to be pluggable, which
could be best done with configurations and sessions. Or it was shared
across all of a group of related entry points, in which case it wanted
to be on the appropriate session subclass for that group of applications.
But like I said, the ability to use Application is there so if people
suddenly find they are using it a lot we can promote it's use again, I
guess. It's just that the concept has been wasting away from lack of use.
Ramon Leon wrote:
> 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
> like this
> ^(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.
>>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
>>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
>>>that acts as the application class. Keeping stuff here
>>would seem to
>>>be what you're looking for.
>>>>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
>>>>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
>>>>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,
>>>>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
>>Seaside mailing list
>>Seaside at lists.squeakfoundation.org
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
More information about the Seaside