Re: Application design patterns
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 [EMAIL PROTECTED] http://www.ineoconcepts.com
Re: Application design patterns
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
On Thu, 24 Jul 2003 02:18:17 -0400 Eric Sammer [EMAIL PROTECTED] 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 [EMAIL PROTECTED] http://frank.wiles.org -
Re: Application design patterns
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 ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Re: Application design patterns
## NOTE : Very simple example which for the most part
## will seem like overkill and it is. Typically the complexity
## of the application can be reduced by breaking it into the
## components below. It makes for easier maintenance.
## Model responsible for data retrieval not formatting.
##In many architectures data will be retrieved from
## some sort of data storage (rdbms).
#--- MODEL ---
package My::Model
sub title { return 'MVC Hello World Example'; }
sub new { return bless {}, shift };
sub enter_room { return 'Hello'; }
sub leave_room { return 'Bye'; }
## Responisble for presentation/formatting of data not
## modifying/retrieving data.
#--- VIEW ---
package My::View
sub new { return bless {}, shift };
sub output {
my $p = { @_ };
print HTML;
html
head
title$p-{'title'}/title
/head
body
h1$p-{'data'}/h1
/html
HTML
}
## Handles user actions/events ... retrieve data through
## model layer and present data through view layer.
#--- CONTROLLER
## Depending on the application (CGI, etc.) initialization code here
my $m = My::Model-new;
my $v = My::View-new;
my $data = $m-leave_room;
if ( $input == 'enter_room' ) {
$data = $m-enter_room;
}
$v-output(
title= $v-title,
data= $data,
);
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?
Re: Application design patterns
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
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 [EMAIL PROTECTED] http://www.ineoconcepts.com
Re: Application design patterns
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
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 [EMAIL PROTECTED] http://www.ineoconcepts.com
Re: Application design patterns
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
Title: Re: Application design patterns Perrin Harkins wrote: 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. Has anyone written an article on it? Or is this still in the domain of: go read the CGI::Application code and sort it out for yourself? This is a topic I've been wondering about recently. I don't have a background in CS. So, I always wonder when tempted to head off into the books... whether or not the return-on-investment will justify the time I could have spent kludging something together that's good enough. I've noted a few FSM modules on CPAN: DFA::Command DFA::Simple DFA::Kleene POE::NFA Bio::Tools::StateMachine::AbstractStateMachine After sifting through google searches I turned up the following article: Essay on Web State Machines by Charles Stross http://www.antipope.org/charlie/attic/webbook/essays/statemach.html Interactive Web Applications Based on Finite State Machines http://www.math.luc.edu/~laufer/papers/isas95.pdf -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
Re: Application design patterns
On Thu, 2003-07-24 at 17:22, Garrett Goebel wrote: Perrin Harkins wrote: 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. Has anyone written an article on it? On state machines as a model for web apps? Probably. And there is this article about CGI::Application: http://www.perl.com/pub/a/2001/06/05/cgi.html You can also read the fairly extensive docs for CGI::Application, Apache::PageKit, OpenInteract, CGI::MxScreen, and others. None of these require you to read code. Essentially, people have looked at the core concepts of web applications -- screens, transitions between screens, expected input on each screen -- and come up with various ways to define them with a data structure instead of with code. Whether or not this is a good idea depends partly on what your application does. Apps that do lots of browsing/publishing don't gain as much from this as ones that have lots of interactivity and forms. I don't have a background in CS. Welcome to the club. This isn't rocket science. After sifting through google searches I turned up the following article: Essay on Web State Machines by Charles Stross http://www.antipope.org/charlie/attic/webbook/essays/statemach.html That one seems to be about managing persistent data, which is a different topic. Interactive Web Applications Based on Finite State Machines http://www.math.luc.edu/~laufer/papers/isas95.pdf That's more like it. - Perrin
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
