Hey,
I am working on Apache::ASP, and would like some feedback from
those interested in ASP code reusability.
I am working on a way to load other file spaces for Apache::ASP's
$Server->MapInclude()... this function represents the underpining
for the way in which $Response->Include() and other such functions
find includes in the search stack consisting of .,Global,IncludesDir
What I am starting to do is to create a shared include area that
I am hoping users can contribute to as part of the core distribution,
or separately if they like. This namespace is Apache::ASP::Share.
As an example, I will be decomping out the MailErrors rendering to
Apache/ASP/Share/CORE/MailError.inc
I would like to create the ability to load this via a normal
ASP call like:
$Response->TrapInclude('Share::CORE/MailError.inc');
The idea here is that a leading Share:: will change the behavior
of MapInclude() on the fly to also include the system Apache/ASP/Share
directory in its path. The upside of this is we have a way to
share components outside the normal search tree, but this search
tree would be pushed onto the stack of .,Global,IncludesDir so
we would look for templates in:
.,Global,IncludesDir,Apache/ASP/Share
This would allow someone to define $Global/CORE/MailError.inc
for example to override the output of the MailErrorsTo function
should one desire for example. CORE would be a reserved namespace
for Apache::ASP system templates, but the Share directory can
be carved up for user contributed includes & modules as in:
<%
# loads Apache/ASP/Calendar.pm
use Apache::ASP::Share::Calendar;
# loads Apache/ASP/Share/Calendar/render.inc
$Response->Include("Share::Calendar/render.inc");
%>
Developers could contribute their own Apache::ASP::Share packages
that contain their templates & modules for reuse. These could
be distributed with Apache::ASP ( assuming GPL licensed ), or
separately to CPAN as Apache::ASP::Share::* module.
This new file loading convention could be further extended
beyond the new Share:: loader as in:
$Response->Include('Super::');
This could mean load the file of the same, but just one
level higher in the include stack. This might be useful to turn
templates into inheritable objects. ( or something like them :)
$Response->Include('Super::include.inc') might mean find
the include.inc one level up in the stack.
Another might be $Response->Include('Self::template.inc')
which might suggest that the include stack start at the
directory current executing include, so for a script calling
it, this would have no effect, as scripts start at '.' anyway.
Overall, I would like a file naming convention that is not
like what one would normally find in an OS. I understand
that in MacPerl, : can be used as a directory separator.
So does that make :: unsafe? I have though about using //
but it seems that // is valid in unix often and is used
in XSLT as a way to refernence a relative node.
What I like about :: is that is looks like a perl package,
so it would be a tipoff that something magical might be
happening to a first time reader of some code.
Perhaps also something more verbose might be safer like:
$Response->Include('::Share::CORE/MailError.inc');
but I fear with the extra leading ::, noone would want to use it!
I considered doing things like $Response->ShareInclude(...),
but then we would have extra names also for ShareTrapInclude()
and ShareExecute(), for each new namespace type. I considered
also $Response->Include({ File => 'CORE/MailError.inc', Share => 1 });
but thought that was too ugly for general use.
I finally considered just pushing the Apache::ASP::Share directory
onto the stack by default, but then thought there would be too
much namespace collision between user contributed code & developer code,
i.e. what if someone already had CORE/ include directory defined,
this might hurt for them to start picking up the CORE includes
without meaning too.
Any thoughts? Thanks much.
-- 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]
