Apache-SSI

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

     

1.96  Fri Oct 16 20:10:54 EDT 1998
   - Added a text() method for getting/setting the contents of the HTML.
     This fixes a bug when used with Apache::SSIChain.  
     [thanks, John Armstrong]

1.95  Sun Oct 11 16:04:19 EDT 1998

   - Doesn't rely on HTML::SimpleParse anymore to parse the HTML, but instead just
     looks for <!--#.*?-->.  This allows nesting: <img src="<!--#whatever-->">,
     and it should be much faster.  HTML::SimpleParse is still used to parse 
     the key-value pairs of attributes for SSI directives. 
     [Randal Schwartz, Rob Hartill]
     
   - <!--#flastmod virtual="whatever"--> now works. [Rob Hartill]
     
   - <!--#perl --> sections now pass $r as the first argument, and there
     are two ways to turn off this behavior (PerlSetVar and named parameter).
     [Ibid]
     

README  view on Meta::CPAN

        eval(). This means you use "==" or "eq" instead of "=" to test equality.
        It also means you can use pre-loaded Perl subroutines in the conditions:

         <!--#if expr="&Movies::is_by_Coen_Brothers($MOVIE)"-->
          This movie is by the Coen Brothers.
         <!--#else-->
          This movie is not by the Coen Brothers.
         <!--#endif-->

        It can't handle very sophistocated Perl though, because it manually
        looks for variables (of the form $var or ${var}, just like
        "mod_include"), and will get tripped up on expressions like
        $object->method or $hash{'key'}. I'll welcome any suggestions for how to
        allow arbitrary Perl expressions while still filling in Apache
        variables.

CHAINING HANDLERS
    There are two fairly simple ways for this module to exist in a stacked
    handler chain. The first uses "Apache::Filter", and your httpd.conf would
    look something like this:

README  view on Meta::CPAN

CAVEATS
    * When chaining handlers via Apache::Filter, if you use <!--#include ...-->
    or <!--#exec cgi=...-->, then Apache::SSI must be the last filter in the
    chain. This is because Apache::SSI uses $r->lookup_uri(...)->run to include
    the files, and this sends the output through C's stdout rather than Perl's
    STDOUT. Thus Apache::Filter can't catch it and filter it.

    If Apache::SSI is the last filter in the chain, or if you stick to simpler
    SSI directives like <!--#fsize-->, <!--#flastmod-->, etc. you'll be fine.

    * Currently, the way <!--#echo var=whatever--> looks for variables is to
    first try $r->subprocess_env, then try %ENV, then the five extra environment
    variables mod_include supplies. Is this the correct order?

TO DO
    Revisit http://www.apache.org/docs/mod/mod_include.html and see what else
    there I can implement.

    It would be nice to have a "PerlSetVar ASSI_Subrequests 0|1" option that
    would let you choose between executing a full-blown subrequest when
    including a file, or just opening it and printing it.

lib/Apache/SSI.pm  view on Meta::CPAN

difference: the boolean expression is evaluated using Perl's eval().  This means
you use C<==> or C<eq> instead of C<=> to test equality.  It also means you can use
pre-loaded Perl subroutines in the conditions:

 <!--#if expr="&Movies::is_by_Coen_Brothers($MOVIE)"-->
  This movie is by the Coen Brothers.
 <!--#else-->
  This movie is not by the Coen Brothers.
 <!--#endif-->

It can't handle very sophistocated Perl though, because it manually looks for
variables (of the form $var or ${var}, just like C<mod_include>), and will get tripped 
up on expressions like $object->method or $hash{'key'}.  I'll welcome any suggestions
for how to allow arbitrary Perl expressions while still filling in Apache variables.

=back

=head1 CHAINING HANDLERS

There are two fairly simple ways for this module to exist in a stacked handler
chain.  The first uses C<Apache::Filter>, and your httpd.conf would look something

lib/Apache/SSI.pm  view on Meta::CPAN

* When chaining handlers via Apache::Filter, if you use <!--#include ...-->
or <!--#exec cgi=...-->, then Apache::SSI must be the last filter in the
chain.  This is because Apache::SSI uses $r->lookup_uri(...)->run to include
the files, and this sends the output through C's stdout rather than Perl's
STDOUT.  Thus Apache::Filter can't catch it and filter it.

If Apache::SSI is the last filter in the chain, or if you stick to simpler SSI
directives like <!--#fsize-->, <!--#flastmod-->, etc. you'll be fine.

* Currently, the way <!--#echo var=whatever--> looks for variables is
to first try $r->subprocess_env, then try %ENV, then the five extra environment
variables mod_include supplies.  Is this the correct order?

=head1 TO DO

Revisit http://www.apache.org/docs/mod/mod_include.html and see what else
there I can implement.

It would be nice to have a "PerlSetVar ASSI_Subrequests 0|1" option that
would let you choose between executing a full-blown subrequest when