[Seaside] Let me see if I understand correctly...(more DB pool, application/session stuff).

[Julian Fitzell]

Well, as Avi and I said, you *can* just subclass App and set it up in 
configuration directly.

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.

<shrug>

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.

Julian

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
> 
> style
> 	^(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: 
>>  'foo'
>>
>>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.
>>
>>Julian
>>
>>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 
>>
>>>>Warren
>>>>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 
>>>>point.
>>>>
>>>>
>>>>_______________________________________________
>>>>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
>>>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>_______________________________________________
>>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
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside