"John D. Leonard II" wrote:
>
> All:
>
> In my never-ending search for ASP truth, I pose the following questions:
>
> 1) Should I gather subroutines common to several ASP files in the GLOBAL.ASA
> file, or should I put them in a PM file? Are there times when one method is
> preferable to another?
>
If the subs are ASP centric, only for use in your ASP scripts, then
global.asa is probably the place for them, but if they encapsulate
important business logic, or logic that might be used in an external
processing application, like a cron job, then I would create
a package / object out of it for sure. One thing pointed out recently
is that subs in the global.asa don't support %> HTML <% , so if you
have an HTML heavy sub, I would probably make an include out of it.
If you want to give your global.asa package a name, set GlobalPackage,
then you could have a separate perl module of that name that has your
subs defined... this would let you keep global.asa & these subs
nicely separated if that is what you want ( might make sense to
keep only ASP events in global.asa, but a few subs mixed in not
a big deal ), but then these subs would also be locally accessible
as in <%= &sub() %>, which they wouldn't be if they weren't in
the same perl package.
> 2) Should an ASP file ever USE a perl module itself, or should all the USE
> clauses be put in the GLOBAL.ASA file?
>
I consider the global.asa the heart of the ASP application,
so I would put all constants, uses, etc. in that file just
to centralize things. One nice things is that subs that are
imported into global.asa will be easily accessible to all
ASP scripts & includes, like:
# global.asa
use Data::Dumper qw(Dumper);
then in an ASP script, you can:
<%= Dumper($Request->Form) %>
Note though that you still want to preload in the parent httpd
these modules, with PerlModule in the httpd.conf, or via
Apache::ASP->Loader() to precompile scripts that might load
that global.asa. This will give you dramatic savings.
If you mix ASP with CGI via Apache::Registry, then you probably
want to keep your uses decomped separately into a startup.pl
kind of file that you PerlRequire for this preloading purpose.
Good topics!
-- Josh
_________________________________________________________________
Joshua Chamas Chamas Enterprises Inc.
NodeWorks Founder Huntington Beach, CA USA
http://www.nodeworks.com 1-714-625-4051
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
