Angus Lees wrote:
>
> On Sun, Nov 26, 2000 at 03:31:52PM -0500, Neil Gunton wrote:
> >
> > Perhaps a directive which allows certain file extensions to be processed
> > by EmbperlObject::Execute(*), but not parsed and interpreted internally.
> >
>
> option 1:
>
> use the "Safe" module and allow user's web pages to include code, but
> limit exactly what opcodes they're allowed.
>
> see the embperl docs, and Safe(3pm)
>
> option 2:
>
> don't use Execute('*') if you don't want embperl to process the
> file. just parse the filename out of $req_rec->uri and use normal perl
> file IO to include its contents.
>
> eg:
> [- $req_rec->uri =~ m|some/web/root/(.*)$|;
> my $file = $1;
> my $buf;
>
> open F, "<$file" or { $req_rec->status(404); exit; };
> print OUT $buf while (read F, $buf, 4096);
> close F;
> -]
Hey Gus,
Thanks for replying. I don't really like this solution, because it is
not very consistent with the way EmbperlObject seems to be headed - that
is, as a tool/framework which enables Object Oriented websites to be
built very intuitively. While it would certainly be possible to
technically achieve the same end-result using pure Perl code, I think
that having the ability for EmbperlObject to be able to include files
without actually executing them (see my previous email) would be more
elegant.
As I said before, I can see EmbperlObject being useful in a dual sense -
both as an interpreter of embedded Perl code, and as a "construction
engine" for OO websites through the EMBPERL_OBJECT_BASE functionality.
JMHO, I'd be interested to see what Gerald thinks of all this (more
work! agh!)
Thanks again, and best wishes
-Neil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
