Let me see if I understand correctly...(more DB pool, application/session stuff).
Locked
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 [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
Rich Warren wrote:
> 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.). Yes. You can see the session id in the URL - it's the _s query parameter. > 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). Yes, you could use a global. Note that all class object are globals. Just like you code "MyApplication new", you can do "MyConnectionPool new", to get a new connection pool instance. Globals, like MyApplication and MyConnectionPool are held in the "Smalltalk" system dictionary. Try "Smalltalk inspect". Just use #at:, #at:put: and #removeKey: to manage the entries. You don't have to add new classes that you define, because the compiler does it for you. Objects that are not classes are also held there. Try: "Smalltalk select: [:e | e isBehavior not]" Here are a bunch of options for your connection pool: 1. Global connection pool instance. You can add your connection pool as a global using: Smalltalk at: #DBConnectionPool put: MyConnectionPool new Then access it in your code using "DBConnectionPool" 2. Singleton Define a class variable and accessor in MyConnectionPool to hold the singleton instance, then access it using: MyConnectionPool default 3. Class as singleton The class is already a global. Simply define all your connection pool methods on the class side. Then access your singleton using just "MyConnectionPool" 4. Class variable in MySession Add a class variable in MySession, maybe call it DBPool. Then within you session, access it using DBPool. There may be a bunch of other ways. One of them is class pools, but I'll leave the explanation of pros/cons of that approach to another time (or to someone else). Of course, you still need to figure out when and where to initialize your connection pool, but that depends on the rest of your application. > 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. Seaside doesn't appear to have it, because the Smalltalk environment already provides it. > Am I missing something, or thinking about this the wrong way? Yes, Smalltalk is a rich development environment. Take some time to explore it (look at tutorials and books that are freely available). _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
On Feb 27, 2006, at 4:34 AM, Yanni Chiu wrote: <<much cut, some included below for reference>> > >> 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. > > Seaside doesn't appear to have it, because the Smalltalk environment > already provides it. No. As you describe it, Smalltalk gives me access to global variables (nothing revolutionary here). I'd always thought global variables were considered "bad form". I really don't see how Smalltalk's particular implementation changes this. Being able to create instance members for the application has at least one real benefit. The instance variable can be automatically initialized and destroyed with the application. I can somewhat duplicate the same thing using lazy instantation of a singleton/ global/session class variable, but (based on my understanding of your description and my experiments with singleton classes) the resources would still be locked into the singleton/global after the application closed, and would need to be discarded manually. This arguably amounts to a memory leak. I've also had problems getting my singleton class to let go of its copy of the instantated pool--so it would see my changes, but would not initialize new instance variables. This resulted in very confusing errors (at least for a Smalltalk beginner). Most importantly, in my mind the seaside application Has-A database pool. This relationship implies that the pool should be an instance variable of the application object. All the other work-arounds just feel like hacks (more or less). Having said that, making the pool a class instance member of the session feels like the best option to me. And the other concerns are probably not worth worrying about. I would love to get more information about class pools. I've seen them mentioned several times (usually immediately followed by the sentence "...are beyond the scope of this article/tutorial." > >> Am I missing something, or thinking about this the wrong way? > > Yes, Smalltalk is a rich development environment. Take some time > to explore it (look at tutorials and books that are freely available). I know you're trying to help, and I thank you for that, but comments like this last one always upset me. It implies that I haven't read smalltalk books or done tutorials--which is completely untrue. I have done a lot of reading and searching on my own before posting here. Now if you have a specific reference that is pertinent to the topic at hand, I would love to see it. But, none of the solutions we've discussed are specific to Smalltalk. Global variables, singleton classes (and variants), class variables: they're all standard OO features. Smalltalk being a "rich development environment" (though most certainly a true statement) does not really bear on the discussion at hand. Anyway, thanks for your input. -Rich- > Here are a bunch of options for your connection pool: > > 1. Global connection pool instance. > > You can add your connection pool as a global using: > Smalltalk at: #DBConnectionPool put: MyConnectionPool new > Then access it in your code using "DBConnectionPool" > > 2. Singleton > > Define a class variable and accessor in MyConnectionPool to hold > the singleton instance, then access it using: > MyConnectionPool default > > 3. Class as singleton > > The class is already a global. Simply define all your connection > pool methods on the class side. Then access your singleton using > just "MyConnectionPool" > > 4. Class variable in MySession > > Add a class variable in MySession, maybe call it DBPool. > Then within you session, access it using DBPool. > > There may be a bunch of other ways. One of them is class pools, > but I'll leave the explanation of pros/cons of that approach > to another time (or to someone else). Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
In reply to this post by Rich Warren
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: [hidden email] > [mailto:[hidden email]] 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 > [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 |
Re: 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: [hidden email] >>[mailto:[hidden email]] 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 >>[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 Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
On Feb 27, 2006, at 5:54 PM, Julian Fitzell wrote: > 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' You can do this from the config UI too - note that there's a select box when you create a new entry point that's almost always left at "Seaside Application", but other options are possible too. If you override #description on the class side of your application subclass, you'll be able to choose it from that list. I use this for WAEntryPoint subclasses that aren't applications at all (and don't create sessions, but act more like straight servlets), on the rare occasions I need that (example: a REST API). Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
Is this documented anywhere (example even)? I could totally use
this, just need to know what to short circuit to avoid session creation. On Feb 27, 2006, at 6:01 PM, Avi Bryant wrote: > > On Feb 27, 2006, at 5:54 PM, Julian Fitzell wrote: > >> 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' > > You can do this from the config UI too - note that there's a select > box when you create a new entry point that's almost always left at > "Seaside Application", but other options are possible too. If you > override #description on the class side of your application > subclass, you'll be able to choose it from that list. > > I use this for WAEntryPoint subclasses that aren't applications at > all (and don't create sessions, but act more like straight > servlets), on the rare occasions I need that (example: a REST API). > > Avi > _______________________________________________ > 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 |
Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
On Feb 27, 2006, at 11:25 PM, Todd Blanchard wrote: > Is this documented anywhere (example even)? I could totally use > this, just need to know what to short circuit to avoid session > creation. It's pretty simple: subclass WAEntryPoint, implement #description on the class side so that it shows up as I described in the config UI, and then override #handleRequest: (takes a WARequest) to return a WAResponse. Avi _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
RE: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
In reply to this post by Rich Warren
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: [hidden email] > [mailto:[hidden email]] 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: [hidden email] > >>[mailto:[hidden email]] 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 > >>[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 > _______________________________________________ > 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 |
Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
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: [hidden email] >>[mailto:[hidden email]] 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: [hidden email] >>>>[mailto:[hidden email]] 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 >>>>[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 >> >>_______________________________________________ >>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 Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Let me see if I understand correctly...(more DB pool, application/session stuff).
|
|
In reply to this post by tblanchard
http://www.techgame.net/projects/Seaside/wiki/CustomRequestHandler
This shows exactly what avi is talking about, and there is a link to the #handleRequest: on the page. Brian On Feb 28, 2006, at 12:25 AM, Todd Blanchard wrote: > Is this documented anywhere (example even)? I could totally use > this, just need to know what to short circuit to avoid session > creation. > > On Feb 27, 2006, at 6:01 PM, Avi Bryant wrote: > >> >> On Feb 27, 2006, at 5:54 PM, Julian Fitzell wrote: >> >>> 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' >> >> You can do this from the config UI too - note that there's a >> select box when you create a new entry point that's almost always >> left at "Seaside Application", but other options are possible >> too. If you override #description on the class side of your >> application subclass, you'll be able to choose it from that list. >> >> I use this for WAEntryPoint subclasses that aren't applications at >> all (and don't create sessions, but act more like straight >> servlets), on the rare occasions I need that (example: a REST API). >> >> Avi >> _______________________________________________ >> 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 _______________________________________________ Seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |