On Fri, Sep 07, 2001 at 04:56:30PM +0800, Stas Bekman wrote:
> This is a proposal paper for Apache::Registry for mod_perl 2.0.
>
> The whole family of Apache::Registry-like modules can be transformed
> from hardcoded packages with specified functionality into a what I
> call Apache::Registry::Cooker packages.
>
> Since various users will want various behavior from various registry
> modules, it'll be too cumbersome to create and maintain all possible
> variations. Of course this could be implemented as a sub-classable
> system, where users wishing their own behavior, need to subclass
> whichever existing module whose behavior is the closest to the desired
> one. I believe that compiling the registry package on the fly will
> make things more flexible.
>
> So I suggest the following spec:
>
> Apache::Registry::Cooker - cook the desired registry handler.
>
> e.g. put in startup.pl:
Or the repurposed <Perl>?
> use Apache::Registry::Cooker;
> Apache::Registry::Cooker::cook
> ({
> package => 'MyCoolRegistry',
> key_alg => 'filename', # (or inode, or uri, or vh+uri, ...)
> stat_src => 1, (0 not to stat on each request)
> flush => 0, # flush namespace on each request
> ... # more features to come
> });
Howabout custom directives, so no startup.pl needed, and can use
different settings in different <Location>, <Directory>, <Proxy>,
whatever (these 4 correspond to your 4 examples, playing the name game a
bit):
PerlRegistryPackage MyCoolRegistry
PerlRegistryKeyAlg filename
PerlRegistryAutoReload 1
PerlRegistryFlush 0
Hmmm, also might want to allow key_alg/PerlRegistryKeyAlg to take a
handler spec:
PerlRegistryKeyAlg My::NameSpaceGenerator
These would all be read by Apache::Registry::handler(). I don't think
we need a new class cooked up for each of these, that seems likely to be
too confusing.
What's more important to me is controlling the parameters of
Apache::Registry, or subclassing it when I get too far away from it's
noremal capabilities.
For instance, setting root of the namespace the script/handler is
compiled in to and the algorithm used to generate the relative part of
the namespace should be able to be set by a parameter. That might be
configured using perlish interpolation:
PerlRegistryNameSpace MyRegistryRoot::${filename}
where $filename/$inode/$uri/$vh is escaped to be a nice package name.
This leads to the natural
PerlRegistryNameSpace MyRegistryRoot::${vh}::${filename}
and the slightly unnatural:
PerlRegistryNameSpace MyRegistryRoot::&{My::key_generating_sub}
or:
PerlRegistryNameSpace &{My::key_generating_sub}
to allow some subroutine to be called to generate the name.
It'd be nice if the new Apache::Registry could use or just cooperate
with Apache::Reload for autostat/autoreload.
Other nice-to-have (IMHO) features
- Allowing a special token in a script like ##__REGISTRY_HANDLER__
that could be used when porting CGI scripts to move all "my" decls
above, so that a script could be partitioned in to globals and
handler code without having to rewrite as a handler. Perhaps the
above template could be modified like so:
package <%= $package_name %> ;
##...
<%= $script_globals_section %>
##...
sub handler {
my ( $r ) = Apache::Request->new( shift ) ;
#line 1 <%= $script_file_name %>
{<%= $script_body_section %>} ;
return OK ;
}
1 ;
Then, porting a script containing named subs could be "tweaked"
by adding a comment to it like so:
use CGI ;
use DBI ;
use strict ;
my $rows ;
my $dbh = ... ;
sub emit_row {
++$rows ;
print tr( map td, @_, ), "\n" ;
}
##__REGISTRY_HANDLER__ (for Apache::Registry operation)
print start_html ;
print "<table>" ;
print_row( @$_ ) for $dbh->selectall_arrayref(...) ;
print "</table>" ;
print "$rows served\n" ;
that might help cgi->registry porters. Only the last 5 statements
would end up in the handler(). Could also have other special tags
to defer some code to a cleanup handler, but you gotta stop
somewhere.
- A source filter, to allow burgeoning young mod_perl hackers to
develop their radical new idea (ie a new templating system) easily.
This is probably best done as an overridable method like
parse_source(). The base class parse_source would (in my perfect,
little world) parse the source for the ##__BEGIN__HANDLER, __END__,
__DATA__, etc. tokens and pass the resulting chunks to the little
templating engine needed to do the following...
- specify the module file generated from a script as a subroutine
template file, so I/you/we could define an application-specific
template like (borrowing ASP tags here):
package <%= $package_name %> ;
use strict ; ## or not...
use My::Standard::Lib ;
use Apache::Util ;
use Apache::File ;
use Apache::Constant ;
use My::Application::Lib ;
use GD ;
*dbh = *My::Globals::dbh ;
## etc., etc.
use base qw( My::AppBase ) ;
## Some little utility routines...
sub empty { ! defined $_[0] || ! length $_[0] }
## etc.
sub handler {
my ( $r ) = Apache::Request->new( shift ) ;
#line 1 <%= $script_file_name %>
{<%= $script_body %>} ;
return OK ;
}
1 ;
This could be done a little less clearly by using a overloadable
Apache::Registry method to return the source code to be eval()ed,
but lately I've been finding that templates work their magic when
writing Perl and C code generators just as well as when writing
HTML or RTF code generators. For instance, you could easily call
$r->dir_config in your nifty little registry module template. Don't
want to start a debate on tempalting engines though, so just being
able to override a method to convert script source code in to
handler() module source code would be nice.
This would turn Apache::Registry in to a templating system backend
and/or a custom application framework, whereby I could use Perl files
("scripts") instead of template files.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
