AxKit2::Transformer::XSP 1.1

AxKit2::Transformer::XSP Perl module contains eXtensible Server Pages.

SYNOPSIS

< xsp:page
xmlns:xsp="http://apache.org/xsp/core/v1" >

< xsp:structure >
< xsp:import >Time::Piece< /xsp:import >
< /xsp:structure >

< page >
< title >XSP Test< /title >
< para >
Hello World!
< /para >
< para >
Good
< xsp:logic >
if (localtime->hour >= 12) {
< xsp:content >Afternoon< /xsp:content >
}
else {
< xsp:content >Morning< /xsp:content >
}
< /xsp:logic >
< /para >
< /page >

< /xsp:page >

XSP implements a tag-based dynamic language that allows you to develop your own tags, examples include sendmail and sql taglibs. It is AxKits 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 Perl code, in one XSP processor and consuming it in another is often confusing and even more often a symptom of misdesign.

Likewise, you may want to lean towards using Perl taglib modules instead of upstream XSLT "LogicSheets". Upstream XSLT LogicSheets work fine, mind you, but using Perl taglib modules results in a simpler pipeline, simpler configuration (just load the taglib modules in httpd.conf, no need to have the correct LogicSheet XSLT page included whereever you need that taglib), a more flexible coding environment, the ability to pretest your taglibs before installing them on a server, and better isolation of interface (the taglib API) and implementation (the Perl module behind it). LogicSheets work, and can be useful, but are often the long way home. That said, people used to the Cocoon environment may prefer them.

Result Code

You can specify the result code of the request in two ways. Both actions go inside a < xsp:logic > tag.

If you want to completely abort the current request, throw an exception:

throw Apache::AxKit::Exception::Retval(return_code => FORBIDDEN);

If you want to send your page but have a custom result code, return it:

return FORBIDDEN;

In that case, only the part of the document that was processed so far gets sent/processed further.

Debugging

If you have PerlTidy installed (get it from http://perltidy.sourceforge.net), the compiled XSP scripts can be formatted nicely to spot errors easier. Enable AxDebugTidy for this, but be warned that reformatting is quite slow, it can take 20 seconds or more on each XSP run for large scripts.

If you enable AxTraceIntermediate, your script will be dumped alongside the other intermediate files, with an extension of ".XSP". These are unnumbered, thus only get one dump per request. If you have more than one XSP run in a single request, the last one will overwrite the dumps of earlier runs.