You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Perrin Harkins <pe...@elem.com> on 2003/07/24 00:17:13 UTC
Re: Application design patterns
On Wed, 2003-07-23 at 18:18, Aleksandr Guidrevitch wrote:
> Are there some common application design patterns using mod_perl + TT2
> ? Any links would be greatly appreciated
There are tutorials on the Template Toolkit site, a recent perl.com
article about TT and Class::DBI, and my article:
http://perl.apache.org/docs/tutorials/apps/scale_etoys/etoys.html
- Perrin
Re: Application design patterns
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2003-07-24 at 09:20, Frank Wiles wrote:
> I too would like to would like to have a better understanding of how
> MVC can be applied to mod_perl. Maybe even HelloWorld sized example
> showing how all of the different components interact?
There's one of those in my original article. I'm not really sure what
to add to it beyond what's there. You can also read previous
discussions on this from the mailing list archives and the docs for
CGI::Application, Apache::PageKit and OpenInteract which all talk about
it to some degree.
If you can ask something more specific, I'll try to answer.
- Perrin
Re: Application design patterns
Posted by Chris Winters <ch...@cwinters.com>.
Frank Wiles wrote:
> I too would like to would like to have a better understanding of how
> MVC can be applied to mod_perl. Maybe even HelloWorld sized example
> showing how all of the different components interact?
No examples, but Andy Wardley sent a great email to the Template
Toolkit mailing list a few months ago about MVC and web apps:
http://lists.ourshack.com/pipermail/templates/2002-November/003974.html
Also no examples but possibly helpful: I place the OpenInteract2
components in an MVC context (will be in next beta):
http://openinteract.sourceforge.net/docs/oi2-snapshot/OpenInteract2/Manual/Architecture.shtml
Chris
--
Chris Winters (chris@cwinters.com)
Building enterprise-capable snack solutions since 1988.
Re: Application design patterns
Posted by Frank Wiles <fr...@wiles.org>.
On Thu, 24 Jul 2003 02:18:17 -0400
Eric Sammer <er...@ineoconcepts.com> wrote:
> 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? Either way, great article.
I too would like to would like to have a better understanding of how
MVC can be applied to mod_perl. Maybe even HelloWorld sized example
showing how all of the different components interact?
---------------------------------
Frank Wiles <fr...@wiles.org>
http://frank.wiles.org
---------------------------------
Re: Application design patterns
Posted by Eric Sammer <er...@ineoconcepts.com>.
Aaron Ross wrote:
> Hi Eric,
>
>>class. 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
>
> I'm not sure if this violates 3 (the models classes have to know what
> resources they need, so i am not sure what wouldn't), but could you use
> a singleton for the resource and a factory to access it? The model
> classes call a "static" factory method that handles the configuration,
> cache, etc...
This is what I'm thinking I'll do. It seems to be the most "natural" in
this case. I was reading this paper by Andy Wardly
http://www.template-toolkit.org/tpc5/camelot/index.html which has a
collection of resource classes that seem to act in a similar method at
some level (providing a resource with a class that could be implemented
as a singleton).
> This solves the problem of having configuration and resource allocation
> code in your model objects. It does mean that you have to write factory
> classes for your resources, but they ought to be quite simple.
Writing factory methods compared to littering code with instantiation of
objects all objects are going to need lends itself to an easy and
obvious first choice. ...For me, at least. ;)
I've done a fair amount of Objective-C (Mac OS X Cocoa and Openstep) and
there's a number of classes that work in a similar fashion - simple,
clean, and functional. The reason I like it is because I don't need to
worry about passing stuff around - just get a static instance and go to
town. (For those interested or in the know, I'm talking about
NSNotificationCenter, NSFileManager, and other similar classes).
Thanks for the input!
--
Eric Sammer
eric@ineoconcepts.com
http://www.ineoconcepts.com
Re: Application design patterns
Posted by Aaron Ross <aa...@alias-i.com>.
Hi Eric,
> class. 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
I'm not sure if this violates 3 (the models classes have to know what
resources they need, so i am not sure what wouldn't), but could you use
a singleton for the resource and a factory to access it? The model
classes call a "static" factory method that handles the configuration,
cache, etc...
This solves the problem of having configuration and resource allocation
code in your model objects. It does mean that you have to write factory
classes for your resources, but they ought to be quite simple.
package MyModel::SomeObject;
...
sub doSomething {
...
my $dbiHandle = MyDBIHandleFactory->getHandle();
...
}
1;
package MyDBIHandleFactory;
sub getHandle {
if (defined $handle) {
return $handle # implement as singleton
}
... read config or something ...
$handle = DBI->connect(...);
}
1;
hth, aaron
Re: Application design patterns
Posted by Perrin Harkins <pe...@elem.com>.
On Thu, 2003-07-24 at 15:17, Eric Sammer wrote:
> 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?
Apache::DBI already caches it. It will ping the handle to make sure
it's active and then hand it back to you. This extra level just skips
the ping if we've already done it on the current request. If you simply
put the handle in a global, it will not get ping-ed on each requests and
you'll have all kinds of problems when connections time out.
Another approach to the same issue is to use the setPingTimeOut() method
of Apache::DBI.
> > 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...
I already gave the talk, but have not completed the article yet.
- Perrin
Re: Application design patterns
Posted by Eric Sammer <er...@ineoconcepts.com>.
Perrin Harkins wrote:
> 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
eric@ineoconcepts.com
http://www.ineoconcepts.com
Re: Application design patterns
Posted by Perrin Harkins <pe...@elem.com>.
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.
For example, to get a DBI handle you would call something like this:
sub get_dbh {
my $r = Apache->request();
my $dbh = $r->pnotes('ESF_DBH');
if (!$dbh) {
$dbh = ESF::Service::DB->new();
$r->pnotes('ESF_DBH', $dbh);
}
return $dbh;
}
This caches the database handle for the rest of the request (one
Apache::DBI ping per request should be enough).
For the Template Toolkit object we want to cache it for the life of the
process, so it would be something like this:
use vars qw($Cached_Template_Object);
sub get_template {
if (!defined $Cached_Template_Object) {
$Cached_Template_Object = Template->new();
}
return $Cached_Template_Object;
}
We also did things in there like setting the include path for the
current request, but you get the idea. These are all class methods in
the ESF::Util class.
> 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.
> 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.
> 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.
I think the way we did it in the above code (don't fetch it until it's
asked for and then cache it as long as you safely can) is a good
approach, but you could refine it by having it set up some things in the
child init hook.
> 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.
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.
- Perrin
Re: Application design patterns
Posted by Eric Sammer <er...@ineoconcepts.com>.
Perrin Harkins wrote:
> There are tutorials on the Template Toolkit site, a recent perl.com
> article about TT and Class::DBI, and my article:
> http://perl.apache.org/docs/tutorials/apps/scale_etoys/etoys.html
I read Perrin's case study awhile ago and it was excellent. Out of
curiosity (and since most of my code written prior to reading said
article looks identical in structure) 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)?
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. I use a
configuration object that parses and holds all site config info (DBI
dsn, user, pass, TT paths, etc.), when apache starts - a singleton style
class. 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
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.
I'm sure I'm either overcomplicating the situation to some great
extentent or the utility class is the way to go (combined with some
caching / shared mem module). Is there some obvious pattern I've missed
or should I just KISS?
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?
Either way, great article.
Thanks in advance.
--
Eric Sammer
eric@ineoconcepts.com
http://www.ineoconcepts.com