On Tue, 2003-03-11 at 19:46, Stas Bekman wrote:
> Stas Bekman wrote:
> > David Culp wrote:
> >
> >> Any Examples of Apache::Filter would be greatly appreciated.
> >
> >
> > http://www.cpan.org/authors/id/G/GE/GEOFF/Apache-Clean-0.05.tar.gz
> >
> > p.s. Apache-Clean-2.x is for mp2.
>
> Hmm, now it's impossible to find (or even know that it exists) Apache::Clean
> for 1.x via the normal tools (other than going to authors/id/G/GE/GEOFF/, but
> you need to know that it exists). Geoff, I'd suggest that you merge 1.x
> version in 2.x's version.
>
> I've attached Apache-Peek-2.0-to-be, for one example of how this could be
> done. Though the obvious problem is that in addition to the inconvenince (the
> source files aren't .pm and .xs), the users of both versions of mod_perl will
> have to figure out whether they need to upgrade their installed package, when
> a new version is released (while the new version is probably changing things
> only for mp1 or mp2).
>
> Unfortunately we don't get any support from CPAN on this issue :( Better ideas
> are welcome.
>
> Back to the all-in-one package methodology:
>
> I think that in order to prevent the development inconvenience as it's in the
> attached Apache-Peek, it's a better approach to have a top level Makefile.PL,
> which writes a new Makefile.PL in one of the subdirs and takes it from there.
> So you have:
>
If possible, I'd like to present another possible solution as well. One
problem with the above is if you need to support people who have both
mod_perl 1.x and mod_perl 2.x on the same system (maybe in cases where a
company or ISP would need to run both side by side to support both
versions.) The end user could change the PREFIX with which the module
is installed and modify their lib path appropriately, installing twice -
once for each version of mod_perl, but I think that is a little rough on
the end user. One trick I used which seems to work pretty well for me
is to have one main module that points to two different mod_perl version
specific modules based on whether we are running in mod_perl 1.x or
2.x. For example (untested):
in Apache::FooBar.pm:
package Apache::FooBar;
use vars qw(@ISA);
...
if(eval "Apache::exists_config_define('MODPERL2')") {
@ISA = qw(Exporter Apache::FooBar2);
require Apache::FooBar2;
Apache::FooBar2->import;
}
else {
@ISA = qw(Exporter Apache::FooBar1);
require Apache::FooBar1;
Apache::FooBar1->import;
}
1;
in Apache::FooBar2.pm:
package Apache::FooBar2;
use vars qw(@ISA @EXPORT);
@ISA = qw(Exporter);
@EXPORT = qw(handler);
...
sub handler {
...
}
1;
(similar thing for Apache::FooBar1.pm)
However this gets cleaner when using method handlers since they don't
need to export anything from the mod_perl version specific modules to
work (this is similar to what I do in Apache::PAR::Registry):
in Apache::FooBar.pm:
package Apache::FooBar;
use vars qw(@ISA);
if(eval "Apache::exists_config_define('MODPERL2')") {
@ISA = qw(Exporter Apache::FooBar2);
require Apache::FooBar2;
}
else {
@ISA = qw(Exporter Apache::FooBar1);
require Apache::FooBar1;
}
1;
in Apache::FooBar2.pm:
package Apache::FooBar2;
...
sub handler : method {
my $class = (@_ >= 2) ? shift : __PACKAGE__;
my $r = shift;
...
}
1;
(similar thing for Apache::FooBar1.pm)
The only problem that I have run into with this is the line:
if(eval "Apache::exists_config_define('MODPERL2')") { ... }
This just doesn't seem to be very clean to me, and fails for mod_perl
2.x if the end user doesn't have either a PerlModule Apache::ServerUtil
or use Apache::ServerUtil in their Apache configuration, but I haven't
yet found a better way to determine the version of mod_perl in all cases
(most ways require a request object, which doesn't exist when the module
is first used, suggestions welcome.)
[snip]
Thanks,
>
> ______________________________________________________________________
--
Nathan Byrd <[EMAIL PROTECTED]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
