On Thu, 2003-07-24 at 02:18, Eric Sammer wrote:
where did you (Perrin) keep objects like your database handle (assuming DBI, but please correct otherwise) and any objects that could be reused (TT, XML parser objects, et al)?
People seem to ask about this frequently, but I don't think we did anything especially interesting there. We just had a simple class full of accessors for these resources that would call factory methods the first time and then cache the result as appropriate.
Sorry to be so cliche / predictable. ;)
This is what I'm sure will wind up happening. I think what I'm looking for will require this kind of framework.
This caches the database handle for the rest of the request (one Apache::DBI ping per request should be enough).
Maybe a stupid question, but what would be the functional difference between dumping the object after each request like you say and using the same method as you describe for the TT object below? I ask because I'm currently treating both objects the same way in two or three of my larger applications. I would assume this is to catch premature database shutdown or network trouble between an app server and database (cluster) on a request by request basis? Is this a performance related choice or an Apache::DBI best practices thing?
For the Template Toolkit object we want to cache it for the life of the process, so it would be something like this:
Right. This is what I currently do.
I see a reference to a utility style class (ESR::Util, IIRC), but after rereading a number of articles and design pattern books, I'm reluctant to go with a "handle holder" object as I've done in the past.
Gang of Four got you spooked? If you have something that works and doesn't cause problems elsewhere in your code, don't fret about it.
Quite true. I think when starting any new large application, as I am now, I like to reevaluate my current design methods and look at anything I might have been able to do better and do it - a bad (or good) habit.
He who feels he got it right in the past never looks for a better way to do it in the future and, thus, stunts all learning and growth... or some such idealistic babble. ;)
That said, I think what I'm learning here is that the uncomfortability with this design method is more in my head than tangible.
What I'd like is to have my model (as in MVC) objects reuse the process or maybe even server shared objects without doing any of these:
1. Using a singleton utility class 2. Needing to pass objects to model objects' new() in teh controllers 3. Instantiating the objects in the model classes themselves
All of those sound legit to me, as long as you don't duplicate code between the objects. I would choose #1, personally.
Yea... that seems to be the ticket, so to speak.
I guess I could use a class to just act as a namespace to hold the objects and create them at server startup time and use a module like IPC::MM, File::Cache, or Cache::Mmap but that feels kludgy and offers no encapsulation for the objects themselves.
No, you can't share things like this between processes. Things with XS code, open sockets, filehandles, etc. are not shareable.
And now that you mention it, it seems so obvious. $Deity only knows what I was thinking...
Perrin - Have you ever considered revealing more about the Etoys project or just the concepts as you applied them? It would be nice to peek at some of the details. Or, is this an NDA situation or some such thing?
Well, I don't have permission to go posting big chunks of code, but in terms of the generally applicable ideas, I think the article covered most of it. The rest has to do with database work and patterns for building model objects, and I hope to cover that in the article version of the talk I gave about object-relational mapping tools at this year's Perl Conference.
Is this past tense and if so, is the article up somewhere? Just curious...
The biggest thing the article didn't cover is the ideas used by the guys coding the more interactive parts of the application to express the state machine implemented by each of their modules in a declarative data structure. This was largely invented by Adam Sussman, who is at TicketMaster now. It was similar to what you see in CGI::Application and some of the other frameworks.
Hm... that is interesting as well. I've been poking at the internals of a lot of the "frameworks" out there and there are some fantastic concepts (Chris Winters' OI comes to mind). Or, there is the distinct possibility that I'm overly obsessed with architecture; that shouldn't be dismissed either... ;)
Thanks for all your input and the great article(s). -- Eric Sammer [EMAIL PROTECTED] http://www.ineoconcepts.com
