You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by "Howell, Steven" <St...@adc.com> on 2002/01/21 12:31:18 UTC
Apache::ASP vs CGI
Hi guys,
I currently have Apache installed on a Unix box, and it is already running
perl CGI scripts quite happily.
I am keen to use Apache::ASP but am unsure as to what benefits it has over
CGI programming. Can anyone argue the case for me?
Thanks for your help!
Steve Howell
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Scoping question
Posted by Joshua Chamas <jo...@chamas.com>.
"John D. Leonard II" wrote:
>
> All:
>
> --> What is the "suggested" way to share variables across callback
> functions. My question relates to getting traversed values out of the
> File::Find routine.
>
Because of "my closure" problems with caching script compilations & mod_perl,
one needs to be very careful with defining callback functions, in particular
to not use a locally defined my scoped variable within it.... as in
DO NOT DO THIS:
my $counter;
sub increment_counter { $counter++ };
$counter will only be defined the first script compilation, so the $counter
value will act as a global between script requests per httpd process.
I would argue that because of problems like these, one should NEVER define
a subroutine directly in an Apache::ASP script. Such subroutines should
be moved to modules, written as includes ( which act like subs ), or use
anonymous subs instead ( see below ).
> the "sub wanted" would not update $dirs. The only way I could get
> information out of the "sub wanted" was to create this global variable.
>
I would do it this way too... particularly:
use vars($global); # declare
$global = []; # init
sub callback { push(@$global, ...); } # use @$global
> --> Is there a better way to share the array $dirs between my may
> program and my callback function &wanted?
>
> sub wanted{
> push @{$dirs},$File::Find::name;
> }
>
> $dirs = [];
> File::Find::find( \&wanted,"./outline" );
> print @{$dirs} . " files found.";
>
This is probably the best way. You might get away with using
a my scoped variable if you use an anonymous sub for your callback like
my $dirs = [];
my $callback = sub { push(@$dirs, $File::Find::name };
File::Find::find($callback, $dir);
The difference here is that &$callback is being redefined
each script execution, so will not cache the first $dirs from
the initial script compilation.
--Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Scoping question
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
All:
--> What is the "suggested" way to share variables across callback
functions. My question relates to getting traversed values out of the
File::Find routine.
Below is my code. It works, although I went through many incarnations
to get it to work properly. Originally, I tried using "my $dirs"; but
the "sub wanted" would not update $dirs. The only way I could get
information out of the "sub wanted" was to create this global variable.
--> Is there a better way to share the array $dirs between my may
program and my callback function &wanted?
--> Are their potential problems with the solution below?
<body>
<h1>List of files</h1>
<%
use vars qw($dirs);
sub wanted{
push @{$dirs},$File::Find::name;
}
$dirs = [];
File::Find::find( \&wanted,"./outline" );
print @{$dirs} . " files found.";
foreach my $file (sort @$dirs){
print "$file" . "<br>";
}
%>
</body>
Thanks,
JL
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: Apache::ASP vs CGI
Posted by Sven Koehler <sk...@upb.de>.
Howell, Steven wrote:
> Hi guys,
>
> I currently have Apache installed on a Unix box, and it is already running
> perl CGI scripts quite happily.
>
> I am keen to use Apache::ASP but am unsure as to what benefits it has over
> CGI programming. Can anyone argue the case for me?
sure.
ASP is a - lets call it API, that was designed my microsoft. bacause it
was designed on base of the microsoft-scripting-host perl was also
possible as scripting language. ActiveState released a perl-port that
was abled to run under windows-scripting-host.
The API has been ported and extended with useful features (that i'm
still missing under MS' ASP).
The API offers you:
a Session-Object
a 'so called' Application-Object
a Reponse-Object
a Request-Object
and locking (synchronisation) and more
a pro is also, that it is HTML-embedded. ASP-capable WYSIWYG-editors can
be used to design the pages.
with ASP you don't have to write a session-management anymore. usually
you would need a databse or a complex file structure to implement this.
ASP-sessions are usually used, to save which user is logged in with
which login etc.
other common things like querystring-parsing, POST-data-parsing etc. are
all done by the ASP-framework.
session-management is done with cookies, and if it should be VERY
secure, than you should use SSL because the cookie can be sniffed and faked.
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: Apache::ASP vs CGI
Posted by "John D. Leonard II" <jo...@ce.gatech.edu>.
Steven:
> I am keen to use Apache::ASP but am unsure as to what
> benefits it has over CGI programming. Can anyone argue the
> case for me?
In my own mind, it greatly depends on the skill level of your CGI
programming. Since Apache::ASP is built primarily on mod_perl and other
existing Apache interfaces, it doesn't offer much in the way of "new
features." On the other hand, using many of these interfaces requires a
signficant level of expertise, increasing the level of training
necessary when bringing new people onto your web development team.
Apache::ASP repackages the various web APIs into consistent, logical,
and modular way. It promotes maintainabilty and modularity. The
concept of a "web application" and it's associated objects and events is
easy to understand. And it (with some restrictions) allows the writing
of "portable" web code between IIS and Apache servers.
My two favorite Apache::ASP features include: The ASP object model
(including the $Application, $Session, $Server, $Request and $Response
objects), and the $Response->Include model for turning .htm files into
subroutines.
Why Apache::ASP over mod_php? Simple: perl. Anything that can be done
in perl, or any code that has already been written can be incorporated
into an Apache::ASP application. The downside? Many people are jumping
on the PHP bandwagon (for a variety of good reasons) so if you are
looking for people to work in your shop, it will be easier to find PHP
web developers.
Hope this helps.
JL
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org