perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James. L" <perl...@yahoo.com>
Subject Re: mod_perl implementation possibility
Date Fri, 16 Mar 2007 16:42:56 GMT

--- Clinton Gormley <clint@traveljury.com> wrote:

> > we are exploring the idea of writing medium to
> large
> > Perl apps in the future which will require
> mod_perl.
> > the current environment is apache 1.3.  having
> read
> > modperl's doc and i am concerned about running
> > multiple unrelated mod_perl apps on one server,
> such
> > as 2 or 3 medium Perl apps. ( issue like database
> > handler pollution etc which i know little about )
> > 
> 
> The only place where you would have an issue with
> running multiple
> applications within one server (even if distributed
> across virtual
> servers) is where :
>  - you have a common module that is used by more
> than one application
>  - that module has the concept of a single set of
> configuration data
>    rather than a per-application set
> 
> Not very clear, so let me give an example.
> 
> If, for example, you were to have a module called
> My::Template, that is
> used by 5 different applications.
> 
> My::Template stores the path to the templates in the
> package wide
> variable $template_path.
> 
> As each application sets its own template_path, it
> overrides the setting
> from the application before.
> 
> The ways to avoid this are:
>  * you pass the template path in to My::Template
> every time you call it
> 
>       process_template ($template_path,
> $template_name, $data)
> 
>  * you create a My::Template object which, amongst
> other things, has 
>    the template path as a property
> 
>      $t = My::Template->new();
>      $t->template_path($path);
>      $t->process_template($template,$data);
> 
>  * for classes which inherit from My::Template,
> instead of using a
>    scalar $template_path, you use a hash, which has
> the class of the  
>    calling object as the key, and that classes
> template path as the
>    value
> 
>      package My::Template;
> 
>      my %Template_Path;
> 
>      sub template_path {
>          my $self = shift;
>          my $class = ref $self || $self;
>          if (@_) {
>             my $path = shift;
>             $Template_Path{$class} = $path};
>          }
>          return $Template_Path{$class}
>     }
> 
> 
> Another example of things with global effects is the
> current working
> directory.  CWD is global, and thus you cannot rely
> on it staying the
> same.  The safest way to handle this is to just use
> absolute filenames.

thanks! I actually have an example of this. A module
for event logging purpose. the global variable is a
hash consists a set of default log flags corresponding
to log messages. 

i can register a new flag/msg to the global variable
in my app and go on with the logging. a simplified
version :

package EventLogging;

my %EVENT_TYPES = ( log_in_ok => 'Login OK', .. );
sub add_event { 
    my ($self, $your_event) = @_;
    while ( my ($k, $v) = each %$your_event ) {
        $EVENT_TYPES{ $k } = $v;
    }
}

use EventLogging;
my $elog = EventLogging->new()
$elog->add_event({...});

now under mod_perl with few apps sharing the same
module, what's the best way to solve this problem ?

mod_perl has an excellent document. but is there a
checklist kind of thing for running mod_perl in
environment like this? where can i read more about
this?

> hth
> 
> Clint
> 
> 

thanks,

James.


 
____________________________________________________________________________________
Finding fabulous fares is fun.  
Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains.
http://farechase.yahoo.com/promo-generic-14795097

Mime
View raw message