Apache :: ASP
  INTRO
  INSTALL
  CONFIG
  SYNTAX
  EVENTS
  OBJECTS
  SSI
  SESSIONS
% XML/XSLT
  CGI
  PERLSCRIPT
  FAQ
  TUNING
  CREDITS
  SUPPORT
  SITES USING
  RESOURCES
  TODO
  CHANGES
  LICENSE

  EXAMPLES

Powered by Apache::ASP
Powered by ModPerl and Apache
Links Checked by NodeWorks

XML/XSLT


Custom Tags with XMLSubsMatch Reference OSS Implementations
XSLT Tranformations  

Custom Tags with XMLSubsMatch

Before XML, there was the need to make HTML markup smarter.
Apache::ASP gives you the ability to have a perl
subroutine handle the execution of any predefined tag,
taking the tag descriptors, and the text contained between,
as arguments of the subroutine.  This custom tag
technology can be used to extend a web developer's abilities
to add dynamic pieces without having to visibly use 
<% %> style code entries.
So, lets say that you have a table that you want to insert for an employee with contact info and the like, you could set up a tag like:
 <my:employee name="Jane" last="Doe" phone="555-2222">
   Jane Doe has been here since 1998.
 </my:employee>
To render it with a custom tag, you would tell the Apache::ASP parser to render the tag with a subroutine:
  PerlSetVar XMLSubsMatch my:employee
Any colons, ':', in the XML custom tag will turn into '::', a perl package separator, so the my:employee tag would translate to the my::employee subroutine, or the employee subroutine in the my package.
Then you would create the my::employee subroutine in the my perl package or whereever like so
  sub my::employee {
    my($attributes, $body) = @_;
    $Response->Include('employee.inc', $attributes, $body);
  }

  <!-- # employee.inc file somewhere else -->
  <% my($attributes, $body) = @_; %>
  <table>
  <% for('name', 'last', 'phone') { %>
    <tr>
      <td><b><%=ucfirst $_ %></b>:</td>
      <td><%= $attributes->{$_} %></td>
    </tr>
  <% } %>
  <tr><td colspan=2><%= $body %></td></tr>
  </table>
  <!-- # end employee.inc file -->
The $Response->Include() would then delegate the rendering of the employee to the employee.inc ASP script include.
Though XML purists would not like this custom tag technology to be related to XML, the reality is that a careful site engineer could render full XML documents with this technology, applying all the correct styles that one might otherwise do with XSLT.
Custom tags defined in this way can be used as XML tags are defined with both a body and without as it
  <my:employee>...</my:employee>
and just
  <my:employee/>
These tags are very powerful in that they can also enclose normal ASP logic, like:
  <my:employee>
    <!-- normal ASP logic -->
    <% my $birthday = &HTTP::Date::time2str(time - 25 * 86400 * 365); %>

    <!-- ASP inserts -->
    This employee has been online for <%= int(rand()*600)+1 %>
    seconds, and was born near <%= $birthday %>.
  </my:employee>
For an example of this custom XML tagging in action, please check out the ./site/eg/xml_subs.asp script. Note the one limitation that currently exists is that tags of the same name may not be used in each other, but otherwise customs tags may be used in other custom tags.

XSLT Tranformations

XML is good stuff, but what can you use it for? The principle is
that by having data and style separated in XML and XSL files, you
can reformat your data more easily in the future, and you 
can render your data in multiple formats, just as easily 
as for your web site, so you might render your site to
a PDA, or a cell phone just as easily as to a browser, and all
you have to do is set up the right XSL stylesheets to do the
transformation (XSLT).
In the first release of XML/XSLT support, ASP scripts may be the source of XML data that the XSL file transforms, and the XSL file itself will be first executed as an ASP script also. The XSLT transformation is handled by XML::XSLT, a perl module, and you can see an example of it in action at the ./site/eg/xslt.xml XML script. Because both the XML and XSL datasources are executed first
To specify a XSL stylesheet, use the setting:
  PerlSetVar XSLT template.xsl
where template.xsl could be any file. By default this will XSLT transform all ASP scripts so configured, but you can separate xml scripts from the rest with the setting:
  PerlSetVar XSLTMatch xml$
where all files with the ending xml would undergo a XSLT transformation. XSLT tranformations are slow however, so to cache XSLT transformations from XML scripts with consistent output, turn on caching:
  PerlSetVar XSLTCacheSize 100
which would allow for the output of 100 transformations to be cached. If the XML data is consistently different as it might be if it were database driven, then the caching will have little effect, but for mostly static pages like real XML docs, this will be a huge win.
Note that XSLT depends on the installation of XML::XSLT, which in turn depends on XML::DOM, and XML::Parser. The caching feature depends on Tie::Cache being installed.

Reference OSS Implementations

For their huge ground breaking XML efforts, these other XML OSS
projects need mention:
  Cocoon - XML-based web publishing, in Java
  http://xml.apache.org/cocoon/

  AxKit - XML web publishing with Apache & mod_perl
  http://www.axkit.org/

  XML::XSLT - Core engine that Apache::ASP uses for XSLT
  http://xmlxslt.sourceforge.net/ 
Copyright © 1998-2000, Joshua Chamas, Chamas Enterprises Inc.