RFC: New MapInclude() file spaces...

[Joshua Chamas <jo...@chamas.com>]

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: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org

Re: RFC: New MapInclude() file spaces...

[Quentin Smith <qu...@comclub.dyndns.org>]

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: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org