Mailing List Archive: ModPerl: ASP

Porting from ActivePerl/IIS to Apache::ASP

Index | Next | Previous | View Threaded

foster_bryce at yahoo

Jul 13, 2004, 4:45 PM

Post #1 of 3 (1572 views)
Permalink

Porting from ActivePerl/IIS to Apache::ASP

We are currently performing a project to convert from ActivePerl/IIS
to Apache::ASP and have
run across issues with variables behaving strangely. After searching
the web, I have a couple
of issues I would like some advice on.

1. Variable scope ...

From the Apache::ASP page (Style Guide):
"One of perl's blessings is also its bane, variables do not need to be
declared, and are by default globally scoped. The problem with this in
mod_perl is that global variables persist from one request to another
even if a different web browser is viewing a page."

Our problem is the original authors of the code assumed variables are
not globally scoped.

Q1.1: How come in other languages, the scope of the variable is
assumed to be for the page unless
defined otherwise (e.g. PHP, ActivePerl, VBScript)?
Q1.2: Is there a configuration option or easy way around this issue?

2. Subroutines ...

From the Apache::ASP page (Style Guide):
"DO NOT add subroutine declarations in scripts. Apache::ASP is
optimized by compiling a script into a subroutine for faster future
invocation."

We have ActivePerl Perlscript pages with
[sample.asp]
<%@ LANGUAGE = PerlScript%>


<%
my $foo = 1;
my $bar = 2;

my ($value) = &getValue($foo, $bar);

$Response->Write("Value = $value<br>\n");

%>
[end sample.asp]

[contents of include.asp]

<%

sub getValue
{
my ($foo, $bar) = @_;

my $value = $foo * $bar;

return $value;
}

%>
[end include.asp]

Q2.1: Since this sub is included in sample.asp, is it considered a
subroutine within a subroutine?
Q2.2: Is there an easy way to convert include.asp to include.pm so I
can use "use include.pm" in our scripts?
Q2.3: Does Apache::ASP support #include virtual=...? It only seems to
work with #include file=...

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

warren at etr-usa

Jul 15, 2004, 12:11 PM

Post #2 of 3 (1486 views)
Permalink

Re: Porting from ActivePerl/IIS to Apache::ASP [In reply to]

Unknown wrote:

> Our problem is the original authors of the code assumed variables are
> not globally scoped.

You mean one of the original authors doesn't understand Perl.

> Q1.1: How come in other languages, the scope of the variable is
> assumed to be for the page unless
> defined otherwise (e.g. PHP, ActivePerl, VBScript)?

First, drop ActivePerl from that. That's a different issue entirely.
Second, the reason has to do with Perl's history, but it's really not
important to argue about it here -- do that on comp.lang.perl.misc.

As for ActivePerl, that's a red herring. ActivePerl is the same
language as used by Apache::ASP, so the variable scoping behaves the
same way. The real issue is mod_perl vs. whatever persistent
interpreter mechanism ActivePerl uses under IIS. The Perl interpreter
is running in a different way in each environment, and that's the source
of the difference in behavior. This is not Apache::ASP's fault. It's
just a portability issue you will have to cope with.

> Q1.2: Is there a configuration option or easy way around this issue?

Rewrite the code so that it doesn't use global variables. This is a
good idea in any case. Turn on the "use strict" pragma, and Perl will
refuse to run your scripts until you either explicitly make all
variables global, or make them lexically scoped.

> Q2.1: Since this sub is included in sample.asp, is it considered a
> subroutine within a subroutine?

Yes. Put it in a Perl module instead, and either "use MyModule" from
each ASP file that needs the routine, or "use" the module in global.asa.

The main downside of this is that you will have to restart Apache each
time you change one of the Perl modules, since Apache::ASP won't
recompile the scripts when a module changes.

> Q2.2: Is there an easy way to convert include.asp to include.pm so I
> can use "use include.pm" in our scripts?

The 'use MyModule' syntax should work just fine in both ASP
implementations. It's a Perl language issue, and as I've pointed out,
the language interpreter is the same in both cases.

This is not a complete replacement for #include. The Perl module method
works only for Perl code. If you want a pure textual include, there's
$Response->Include(), but you still don't want to put subroutines in the
included file.

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

josh at chamas

Jul 16, 2004, 12:28 PM

Post #3 of 3 (1480 views)
Permalink

Re: Porting from ActivePerl/IIS to Apache::ASP [In reply to]

Quoting Warren Young <warren [at] etr-usa>:

> Unknown wrote:
>
> > Our problem is the original authors of the code assumed variables are
> > not globally scoped.
>
> You mean one of the original authors doesn't understand Perl.
>

Besides Warren's excellent response to your original email, I would like to add
a few things...

> > Q1.1: How come in other languages, the scope of the variable is
> > assumed to be for the page unless
> > defined otherwise (e.g. PHP, ActivePerl, VBScript)?
>
> First, drop ActivePerl from that. That's a different issue entirely.
> Second, the reason has to do with Perl's history, but it's really not
> important to argue about it here -- do that on comp.lang.perl.misc.
>

Consider the alternative to caching things where globals and such persist, the
cost and overhead to resetting things things can be expensive. If you really
want things to be cleaner, you can set NoCache 1 which will at least recompile
scripts each time.

> > Q1.2: Is there a configuration option or easy way around this issue?
>

Settings "UseStrict 1" is a great way to find out which one of your scripts has
variables incorrectly declared.

> Yes. Put it in a Perl module instead, and either "use MyModule" from
> each ASP file that needs the routine, or "use" the module in global.asa.
>

You can also move the subs to the global.asa for auto import to your scripts.

> The main downside of this is that you will have to restart Apache each
> time you change one of the Perl modules, since Apache::ASP won't
> recompile the scripts when a module changes.
>

Try also Apache::Reload and StatINC settings to deal with the reload issue while
developing.

Regards,

Josh

---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe [at] perl
For additional commands, e-mail: asp-help [at] perl

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads