Tue Jun 22 12:15:30 2004
Apache::AxKit::Language::XSP - eXtensible Server Pages
XSP has a very low-level syntax. In order to get around this we encourage everyone to use
taglibs instead. This document details the low level details of XSP, and so may not be what
you want to be reading. Instead check out Apache::AxKit::Language::XSP::TaglibHelper and
Apache::AxKit::Language::XSP::SimpleTaglib which allow you to cleanly separate logic from
the contents of your XSP pages (in MVC terms, your XSP page becomes the Controller and your
taglib contains the logic, making it the Model).
<xsp:page
xmlns:xsp="http://apache.org/xsp/core/v1">
<xsp:structure>
<xsp:import>Time::Object</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 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.
A warning to namespace users: Do not expect your namespace _prefixes_ to
come out of an XSP transformation as they were fed in. But since you are using
namespaces, this doesn't really matter. You just have to make sure that
each and every step in your transformation process is namespaces aware
and uses the correct namespace declarations.
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.
This is the top level element, although it does not have to be. AxKit's
XSP implementation can process XSP pages even if the top level element
is not there, provided you use one of the standard AxKit ways to turn
on XSP processing for that page. See AxKit.
The attribute language="Perl" can be present, to mandate the language.
This is useful if you expect people might mistakenly try and use this
page on a Cocoon system. The default value of this attribute is "Perl".
XSP normally swallows all whitespace in your output. If you don't like
this feature, or it creates invalid output, then you can add the
attribute: indent-result="yes"
parent: <xsp:page>
This element appears at the root level of your page before any non-XSP
tags. It defines page-global "things" in the <xsp:logic> and
<xsp:import> tags.
parent: <xsp:structure>
Use this tag for including modules into your code, for example:
<xsp:structure>
<xsp:import>DBI</xsp:import>
</xsp:structure>
parent: <xsp:structure>, any
The <xsp:logic> tag introduces some Perl code into your page.
As a child of <xsp:structure>, this element allows you to define
page global variables, or functions that get used in the page. Placing
functions in here allows you to get around the Apache::Registry
closures problem (see the mod_perl guide at http://perl.apache.org/guide
for details).
Elsewhere the perl code contained within the tags is executed on every
view of the XSP page.
Warning: Be careful - the Perl code contained within this tag is still
subject to XML's validity constraints. Most notably to Perl code is that
the & and < characters must be escaped into & and < respectively.
You can get around this to some extent by using CDATA sections. This is
especially relevant if you happen to think something like this will work:
<xsp:logic>
if ($some_condition) {
print "<para>Condition True!</para>";
}
else {
print "<para>Condition False!</para>";
}
</xsp:logic>
The correct way to write that is simply:
<xsp:logic>
if ($some_condition) {
<para>Condition True!</para>
}
else {
<para>Condition False!</para>
}
</xsp:logic>
The reason is that XSP intrinsically knows about XML!
parent: <xsp:logic>
This tag allows you to temporarily "break out" of logic sections to generate
some XML text to go in the output. Using something similar to the above
example, but without the surrounding <para> tag, we have:
<xsp:logic>
if ($some_condition) {
<xsp:content>Condition True!</xsp:content>
}
else {
<xsp:content>Condition False!</xsp:content>
}
</xsp:logic>
This tag generates an element of name equal to the value in the attribute
name. Alternatively you can use a child element <xsp:name> to specify
the name of the element. Text contents of the <xsp:element> are created
as text node children of the new element.
Generates an attribute. The name of the attribute can either be specified
in the name="..." attribute, or via a child element <xsp:name>. The
value of the attribute is the text contents of the tag.
Normally XML comments are stripped from the output. So to add one back in
you can use the <xsp:comment> tag. The contents of the tag are the
value of the comment.
Create a plain text node. The contents of the tag are the text node to be
generated. This is useful when you wish to just generate a text node while
in an <xsp:logic> section.
This is probably the most useful, and most important (and also the most
complex) tag. An expression is some perl code that executes, and the results
of which are added to the output. Exactly how the results are added to the
output depends very much on context.
The default method for output for an expression is as a text node. So for
example:
<p>
It is now: <xsp:expr>localtime</xsp:expr>
</p>
Will generate a text node containing the time.
If the expression is contained within an XSP namespaces, that is either a
tag in the xsp:* namespace, or a tag implementing a tag library, then an
expression generally does not create a text node, but instead is simply
wrapped in a Perl do {} block, and added to the perl script. However,
there are anti-cases to this. For example if the expression is within
a <xsp:content> tag, then a text node is created.
Needless to say, in every case, <xsp:expr> should just "do the right
thing". If it doesn't, then something (either a taglib or XSP.pm itself)
is broken and you should report a bug.
Writing your own taglibs can be tricky, because you're using an event
based API to write out Perl code. You may want to take a look at the
Apache::AxKit::Language::XSP::TaglibHelper module, which comes with
AxKit and allows you to easily publish a taglib without writing
XML event code. Recently, another taglib helper has been developed,
Apache::AxKit::Language::XSP::SimpleTaglib. The latter manages all the
details described under 'Design Patterns' for you, so you don't really
need to bother with them anymore.
A warning about character sets: All string values are passed in and
expected back as UTF-8 encoded strings. So you cannot use national characters
in a different encoding, like the widespread ISO-8859-1. This applies to
Taglib source code only. The XSP XML-source is of course interpreted according
to the XML rules. Your taglib module may want to 'use utf8;' as well, see
perlunicode and utf8 for more information.
These patterns represent the things you may want to achieve when
authoring a tag library "from scratch".
Example:
<mail:sendmail>...</mail:sendmail>
Solution:
Start a new block, so that you can store lexical variables, and declare
any variables relevant to your tag:
in parse_start:
if ($tag eq 'sendmail') {
return '{ my ($to, $from, $sender);';
}
Often it will also be relevant to execute that code when you see the end
tag:
in parse_end:
if ($tag eq 'sendmail') {
return 'Mail::Sendmail::sendmail(
to => $to,
from => $from,
sender => $sender
); }';
}
Note there the closing of that original opening block.
Example:
<mail:to>...</mail:to>
Solution:
Having declared the variable as above, you simply set it to the empty
string, with no semi-colon:
in parse_start:
if ($tag eq 'to') {
return '$to = ""';
}
Then in parse_char:
sub parse_char {
my ($e, $text) = @_;
$text =~ s/^\s*//;
$text =~ s/\s*$//;
return '' unless $text;
$text = Apache::AxKit::Language::XSP::makeSingleQuoted($text);
return ". $text";
}
Note there's no semi-colon at the end of all this, so we add that:
in parse_end:
if ($tag eq 'to') {
return ';';
}
All of this black magic allows other taglibs to set the thing in that
variable using expressions.
For example, generates a Text node in one place or generates a scalar in another
context.
Solution:
use start_expr(), append_to_script(), end_expr().
Example:
<example:get-datetime format="%Y-%m-%d %H:%M:%S"/>
in parse_start:
if ($tag eq 'get-datetime') {
start_expr($e, $tag); # creates a new { ... } block
my $local_format = lc($attribs{format}) || '%a, %d %b %Y %H:%M:%S %z';
return 'my ($format); $format = q|' . $local_format . '|;';
}
in parse_end:
if ($tag eq 'get-datetime') {
append_to_script($e, 'use Time::Object; localtime->strftime($format);');
end_expr($e);
return '';
}
Explanation:
This is more complex than the first 2 examples, so it warrants some
explanation. I'll go through it step by step.
start_expr(...)
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
a return, which appends more code onto the generated perl script, so we
get:
do {
my ($format); $format = q|%a, %d %b %Y %H:%M:%S %z|;
Now we immediately receive an end_expr, because this is an empty element
(we'll see why we formatted it this way in #5 below). The first thing we
get is:
append_to_script($e, 'use Time::Object; localtime->strftime($format);');
This does exactly what it says, and the script becomes:
do {
my ($format); $format = q|%a, %d %b %Y %H:%M:%S %z|;
use Time::Object; localtime->strftime($format);
Finally, we call:
end_expr($e);
which closes the do {} block, leaving us with:
do {
my ($format); $format = q|%a, %d %b %Y %H:%M:%S %z|;
use Time::Object; localtime->strftime($format);
}
Now if you execute that in Perl, you'll see the do {} returns the last
statement executed, which is the localtime-strftime()> bit there,
thus doing exactly what we wanted.
Note that start_expr, end_expr and append_to_script aren't exported
by default, so you need to do:
use Apache::AxKit::Language::XSP
qw(start_expr end_expr append_to_script);
Example:
<util:include-uri uri="http://server/foo"/>
or
<util:include-uri>
<util:uri><xsp:expr>$some_uri</xsp:expr></util:uri>
</util:include-uri>
Solution:
There are several parts to this. The simplest is to ensure that whitespace
is ignored. We have that dealt with in the example parse_char above. Next
we need to handle that variable. Do this by starting a new block with the
tag, and setting up the variable:
in parse_start:
if ($tag eq 'include-uri') {
my $code = '{ my ($uri);';
if ($attribs{uri}) {
$code .= '$uri = q|' . $attribs{uri} . '|;';
}
return $code;
}
Now if we don't have the attribute, we can expect it to come in the
<util:uri> tag:
in parse_start:
if ($tag eq 'uri') {
return '$uri = ""'; # note the empty string!
}
Now you can see that we're not explicitly setting $uri, that's because the
parse_char we wrote above handles it by returning '. q|$text|'. And if we
have a <xsp:expr> in there, that's handled automagically too.
Now we just need to wrap things up in the end handlers:
in parse_end:
if ($tag eq 'uri') {
return ';';
}
if ($tag eq 'include-uri') {
return 'Taglib::include_uri($uri); # execute the code
} # close the block
';
}
Example:
<esql:get-column column="user_id"/>
vs
<esql:get-column>
<esql:column><xsp:expr>$some_column</xsp:expr></esql:column>
</esql:get-column>
Solution:
This is a combination of patterns 3 and 4. What we need to do is change
#3 to simply allow our variable to be added as in #4 above:
in parse_start:
if ($tag eq 'get-column') {
start_expr($e, $tag);
my $code = 'my ($col);'
if ($attribs{col}) {
$code .= '$col = q|' . $attribs{col} . '|;';
}
return $code;
}
if ($tag eq 'column') {
return '$col = ""';
}
in parse_end:
if ($tag eq 'column') {
return ';';
}
if ($tag eq 'get-column') {
append_to_script($e, 'Full::Package::get_column($col)');
end_expr($e);
return '';
}
Example:
<esql:no-results>
No results!
</esql:no-results>
Solution:
The problem here is that taglibs normally recieve character/text events
so that they can manage variables. With a conditional tag, you want
character events to be handled by the core XSP and generate text events.
So we have a switch for that:
if ($tag eq 'no-results') {
$e->manage_text(0);
return 'if (AxKit::XSP::ESQL::get_count() == 0) {';
}
Turning off manage_text with a zero simply ensures that immediate children
text nodes of this tag don't fire text events to the tag library, but
instead get handled by XSP core, thus creating text nodes (and doing
the right thing, generally).
Do not consider adding in the 'do {' ... '}' bits yourself. Always
leave this to the start_expr, and end_expr functions. This is because the
implementation could change, and you really don't know better than
the underlying XSP implementation. You have been warned.
Edit This Page
/
Show Page History
/
Home