Hi-
Comments are mixed in below.
HTH,
--Quentin
On Saturday, April 20, 2002, at 04:12 PM, Joshua Chamas wrote:
> 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.
Sounds great!
>
> 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.
Well, I think you would be safe. :: on MacOS is like .. on Unix, so
MacHD:TheDir::TheSecondDir:file.txt is like MacHD:TheSecondDir:file.txt.
Since relative paths on MacOS require a leading :, the only way this
could be mis-interpreted would be for someone to do MacHD::blah, but
that makes no sense on MacOS because there is no root directory. As long
as your code doesn't think that "::TheModule" is a valid way of
specifying the search path, you should be fine. Don't forget this is all
a moot point on OS X, because it uses normal *nix paths.
>
> 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!
See above, this would NOT work on a mac.
>
> 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.
>
This seems too un-perlish.
> 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.
I agree.
>
> Any thoughts? Thanks much.
BTW, I just realized this is all probably not important, since AFAIK
Apache::ASP doesn't run on macs. However, you might be able to get it to
run as a CGI - I haven't tried it, but if you want me to, just give a
holler.
>
> -- 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]
