AxKit2

 view release on metacpan or  search on metacpan

lib/AxKit2/Config.pm  view on Meta::CPAN

=head1 CASCADING

Lookup of values cascades from the location to the server to the global config
class. So if the docroot isn't set in the C<< <Location> >> section, the config
class will automatically cascade down to the C<< <Server> >> section to look
for the value, and down to the global level if it is still not found.

=head1 LOCATION MATCHING

How AxKit2 matches a request to a particular C<< <Location> >> section is at
best described as naive. It simply looks for the last matching location section
in the config file. This has consequences that I should document better.

=cut

lib/AxKit2/HTTPHeaders.pm  view on Meta::CPAN

        $res->response_code == 304 || # not modified
        $res->response_code == 204 || # no content
        $self->request_method eq 'HEAD';

    # fail-safe, no keep-alive
    return 0;
}

=head2 C<< $obj->res_keep_alive_options >>

Determine if an options response from a backend looks like it can do keep-alive.

=cut
sub res_keep_alive_options {
    my AxKit2::HTTPHeaders $self = $_[0];
    return $self->res_keep_alive(undef, 1);
}

=head2 C<< $obj->res_keep_alive( REQUEST_HEADERS ) >>

Given C<$obj> is the response headers, answers the question: "is the backend

lib/AxKit2/Transformer/XSP.pm  view on Meta::CPAN

XSP implements a tag-based dynamic language that allows you to develop
your own tags, examples include sendmail and sql taglibs. It is AxKit's
way of providing an environment for dynamic pages. XSP is originally part
of the Apache Cocoon project, and so you will see some Apache namespaces
used in XSP.

Also, use only one XSP processor in a pipeline.  XSP is powerful enough
that you should only need one stage, and this implementation allows only
one stage.  If you have two XSP processors, perhaps in a pipeline that
looks like:

    ... => XSP => XSLT => XSLT => XSP => ...

it is pretty likely that the functionality of the intermediate XSLT
stages can be factored in to either upstream or downstream XSLT:

    ... => XSLT => XSP => XSLT => ...

This design is likely to lead to a clearer and more maintainable
implementation, if only because generating code, especially embedded

lib/AxKit2/Transformer/XSP.pm  view on Meta::CPAN

Explanation:

This is more complex than the first 2 examples, so it warrants some 
explanation. I'll go through it step by step.

  $e->start_expr($tag)

This tells XSP that this really generates a <xsp:expr> tag. Now we don't
really generate that tag, we just execute the handler for it. So what
happens is the <xsp:expr> handler gets called, and it looks to see what
the current calling context is. If its supposed to generate a text node,
it generates some code to do that. If its supposed to generate a scalar, it
does that too. Ultimately both generate a do {} block, so we'll summarise 
that by saying the code now becomes:

  do {

(the end of the block is generated by end_expr()).

Now the next step (ignoring the simple gathering of the format variable), is