perl-embperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Gunton <n...@nilspace.com>
Subject Re: Testing 2.x with production 1.x code
Date Thu, 10 Jul 2003 14:43:18 GMT
Thanks Kee, this looks very interesting. However I think for now I will
just test Embperl 2.0bx with my 1.x codebase as it is now, unchanged,
with no extras - apart from the small changes that don't break the 1.x
code (e.g. adding parentheses to [$ foreach $]). Gerald apparently has
designed things so that 1.x code should be able to work unchnaged in
2.0, so I feel it would be most useful for testing purposes to try to do
just that...

I'm constantly being surprised at just what people can do with Perl. It
really does seem to be the ultimate swiss army knife of programming
languages...

Thanks again

-Neil

Kee Hinckley wrote:
> 
> I wrote this a while ago, I haven't tested it on recent versions of
> 2.0.  But feel free to try it.  My problem was that I had code which
> was doing things like using HTML::Embperl::OUT and it would break if
> used with 2.0.  The was to map each name space into a common generic
> space Embperlx::Util.  It doesn't deal with actually differences
> between the two (although you could make it do so), but it should
> allow you to make calls without worrying about which one is in use.
> One problem is if you are using both libraries in the same shared
> Apache address space this is going to default to Embperl::, which
> may not be what you want.
> 
> #
> # If you have a perl library that needs to access HTML::Embperl OR Embperl
> # internals, this will create a name space that contains the necessary variables
> # regardless of which package is currently in use.  This should make it easier
> # to write libraries that work with both systems.
> #
> # Simple add "use Embperlx::Util" to your library, and then instead of
> # accessing $HTML::Embperl::escmode or Embperl::OUT, refer to the variables
> # as Embperlx::Util::varname and things should work fine in either context.
> #
> package Embperlx::Util;
> 
> CreateAliases();
> sub CreateAliases {
>     if (defined $Embperl::escmode) {
>         Embperl::Util::CreateAliases();
>     } elsif (defined $HTML::Embperl::escmode) {
>         my $r = new Embperlx::Util::FakeReq();
>         HTML::Embperl::Req::CreateAliases($r);
>     } else {
>         #!! Eventually we should fake some common variables here
>         warn("Not running inside Embperl");
>     }
> }
> 
> #
> # Embperl has a clean CreateAliases call that inserts variables into
> # the name space of the caller.  However HTML::Embperl expects to be
> # passed a special HTML::Embperl::Req object.  Fortunately it only
> # wants two methods out of that, and we can fake them both.
> #
> package Embperlx::Util::FakeReq;
> 
> sub new {
>     my $pkg = shift;
>     my $this = bless {}, $pkg;
> 
>     $this->{package} = caller;
> 
>     return $this;
> }
> 
> sub CurrPackage {
>     my $this = shift;
> 
>     return $this->{package};
> }
> 
> sub ApacheReq {
>     my $this = shift;
> 
>     return $HTML::Embperl::req_rec;
> }
> 1;
> 
> --
> Kee Hinckley
> http://www.messagefire.com/          Anti-Spam Service for your POP Account
> http://commons.somewhere.com/buzz/   Writings on Technology and Society
> 
> I'm not sure which upsets me more: that people are so unwilling to accept
> responsibility for their own actions, or that they are so eager to regulate
> everyone else's.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org


Mime
View raw message