|
XML::XPathScript::Processor - the XML transformation engine in XML::XPathScript |
XML::XPathScript::Processor - the XML transformation engine in XML::XPathScript
In a stylesheet ->{testcode} sub for e.g. Docbook's <ulink>
>> tag:
my $url = findvalue('@url',$self);
if (findnodes("node()", $self)) {
# ...
$t->{pre}=qq'<a href="$url">';
$t->{post}=qq'</a>';
return DO_SELF_AND_KIDS;
} else {
$t->{pre}=qq'<a href="$url">$url</a>';
$t->{post}=qq'';
return DO_SELF_ONLY;
};
At the stylesheet's top-level one often finds:
<%= apply_templates() %>
The XML::XPathScript distribution offers an XML parser glue, an
embedded stylesheet language, and a way of processing an XML document
into a text output. This package implements the latter part: it takes
an already filled out $t template hash and an already parsed
XML document (which come from the XML::XPathScript manpage behind the scenes),
and provides a simple API to implement stylesheets. In particular, the
apply_templates function triggers the recursive expansion of
the whole XML document when used as shown in SYNOPSIS.
All of these functions are intended to be called solely from within
the ->{testcode} templates or <% %> or <%= %>
blocks in XPathScript stylesheets. They are automatically exported to
both these contexts.
->{testcode} routines
instead of the numeric values which are harder to
remember. Specifically:
<
$t-{pre} >>, followed by the result of the call to
apply_templates on the subnodes, followed by $t->{post}.
$t->{pre}, followed by $t->{post}.
$t->{pre} and $t->{post} will frame the text instead of
replacing it.
E.g.
$t->{pre} = '<text/>';
# will do <foo>bar</foo> => <foo><text/></foo>
$t->{pre} = '<t>';
$t->{post} = '</t>';
$t->{testcode} = sub{ DO_TEXT_AS_CHILD };
# will do <foo>bar</foo> => <foo><t>bar</t></foo>
See XPath scalar return values considered harmful in the XML::XPathScript manpage on why this is useful.
apply_templates("/")).
Calls to apply_templates() may occur both implicitly (at the top of
the document, and for rendering subnodes when the templates choose to
handle that by themselves), and explicitly (because testcode
routines require the XML::XPathScript::Processor to
DO_SELF_AND_KIDS).
If appropriate care is taken in all templates (especially the
testcode routines and the text() template), the string result of
apply_templates need not be UTF-8 (see
binmode in the XML::XPathScript manpage): it is thus possible to use XPathScript
to produce output in any character set without an extra translation
pass.
testcode routines to invoke a template by
name, even if the selectors do not fit (e.g. one can apply template B
to an element node of type A). Returns the stylesheeted string
computed out of $node just like apply_templates would.
The dangerous part of the story is when concatenating a non-tainted string with a tainted one, as it causes the whole string to be re-interpreted into UTF-8, even the part that was supposedly meaningless character-wise, and that happens in a nonportable fashion (depends on locale and Perl version). So don't do that - and use this function to prevent that from happening.
Right now XML::XPathScript::Processor is just an auxillary module to the XML::XPathScript manpage which should not be called directly: in other words, XPathScript's XML processing engine is not (yet) properly decoupled from the stylesheet language parser, and thus cannot stand alone.
|
XML::XPathScript::Processor - the XML transformation engine in XML::XPathScript |