Server Scripting

There are two steps to the process:
- Trigger the alternative theme that writes XML
- Write the theme that renders XML

1)
In your page.tpl.php, add this code at the top

<?php
if (($_GET["format"])==("xml")) {
include 'xml.page.tpl.php'; /*call the alternative template file */
return; }
?>

In my case, I am looking to see if there is a querystring format=xml as a condition

Do the same for node.tpl.php and this time point to an alternative node.tpl.php

<?php
if (($_GET["format"])==("xml")) {
include 'xml.node.tpl.php'; /*call the alternative template file */
return; }
?>

2) The template files:
Example xml.page.tpl.php and xml.node.tpl.php (the naming format is arbitrary and can be anything)

<?php
$xml_header='<?xml version="1.0" encoding="ISO-8859-1"?>';
header('Content-type: text/xml');
print $xml_header;
?>
<drupal_page>
<?php print $content; ?>
</drupal_page>

and

<node>
<link><?php print $node_url ?></link>
<title><?php print $title ?></title>
<content><?php print $content ?></content>
</node>

There you go, test the code and correct any coding errors and it should work (I assume that you have already tested the implementation on cmsproducer.com). If you need help with this, please ask.

Please note that this code is just an example of greater things that you can accomplish by creatively theming CMS data. You call pull-in more fields, and even take the resultant XML and manipulate it using XSLT, or consume it into Adobe flash for presentation... If you come up with some creative application, please share them with th rest of us by commenting on this website, or on Drupal.org: Drupal to XML: By theme, Server-side manipulation

An effective, flexible and useful Web Content Management System (WCMS) feature

Like many leading Web Content Management Systems, Drupal is especially flexible and powerful when it comes to providing administrators and content managers and publishers with the ability to easily create and maintain custom and flexible user-friendly paths and URLs/URI. Despite the typical assumption that a dynamic CMS application has to suffer from the inability to generate or accommodate the custom paths, Drupal makes it possible to match the flexibility and choice of a static, file-system-based web-site content path system while maintaining the power and flexibility of a Web Content management System.

General Requirements of a WCMS friendly path system

1. To enable content creators and optimizers to create and apply human readable URL paths that are relevant to the page content in keywords and inference.
2. Create URLs that are short and easy to remember for marketing programs and printed materials
3. Allow the creation of path aliases to enable traffic channels to be tracked by using different paths for different sources
4. Facilitate the option to create paths that mimic the file-system based URLs delimited by "/". This is useful for the migration of already established physical paths that are logical, semantic and have high pageRank
5. Make the selected paths independent of the destination GUID so that one established path can be pointed at any location, and changed as necessary
6. Ability to create more than one alias per physical content item: Especially in the migration, there are many pages that are redundant, and for the first 6-12 months, we will need to maintain 301 and 302 header redirects from many paths to one single resource

Basic features of a WCMS path alias management tool

1. Integrate with the content creation work flow to enable content publishers to select a suitable path and verify that the path does not already exist - Paths by definition of URI have to be unique, and an effective path management system has to be able to alert the publisher when he/she attempts to create a duplicate path/URL
2. The alias management tool itself will provide the option to edit and modify existing URL paths to enable the creation of paths without having to create a content object (e.g http://cmsproducer.com/nature-photography pointing to idonny.com), or to change the destination of an existing path/destination pair
3. The friendly URL has to be able to mask characters that are reserved by the web-server/Operating System to eliminate the restriction not to use "-" in friendly paths
4. The paths do not need to have file extension *.aspx, *.asp, *.php, *.htm, *.html unless the user chooses to create them or other kinds of extensions to mimic a legacy URL that is being replicated. - Ideally, all paths should be folder-level to eliminate the need for a technology specific extension that will be a liability if future choices of a CMS platform or technology. For instance, if a CMS requires the use of an extension, it will unnecessarily expose the technology in use (*.aspx, *.asp, *.php, *.htm, *.html), and if in future the site-owner chooses to migrate to a different web-server technology, it will prove unnecessarily difficult or impossible to maintain the same URLs/paths without having to translate them

Demerits of Presentational Markup in handling data markup

Imagine if you could take pieces of existing HTML content and programmatically slice, dice and transform it into a new document that fits new criteria! You cannot reliably do that with conventional HTML because it is not always well-formed and hierarchical enough to enable DOM navigation to find and extract required information. This is especially difficult and even impossible when the markup is not semantic (using tables and other presentational markup). Do not loose hope though. The above scenario is possible if the markup is in semantic XHTML.

XML/XSLT to the rescue

The object of this document is not to establish or discuss the possibility of storing content in HTML or XHTML, but the markup, extraction and manipulation of data in XML by means of XSLT (Extensible Stylesheet Language for Transformations). In a previous document related to this one, we addressed the process of applying an XSLT file to XML data to result in a new XML, XHTML, or any other format (RTP, CSV,TSV,ASCII and so on).

In this document, we will review how to accomplish this process on the server. This process has a significant advantage over client-size XML processing in that it is not dependent on the browser's ability to parse and process XML/XSLT. In addition, even when the browser has a parser, the differences and characteristics of every browser and parser come into play thereby compromising the reliability of the process. Some clients (PDA, WAP etc) may be excluded as they may not have an XML parser, and an XSLT processor.

Procedure

The process involves creating an server object and procedure that can apply the XSLT file to a given XML file and place the output into a variable that can be further processed, written into a file or printed to the screen.

PHP

In PHP, the commonly used XSLT processor especially upto PHP 4.x is the Sablotron XSLT processor. Below is sample code. This method enabled the use of an XML and XSLT file located on a remote server. This is more practical than local files as in the latter case, the information can be extracted and processed by other means.

<?php // $xml and $xsl contain the XML and XSL data...
$xml = implode('',file('http://www.cmsproducer.com/labs/xmlpagemarkup/myback.xml'));
$xsl = implode('',file('http://www.cmsproducer.com/labs/xmlpagemarkup/idonny.xsl'));

$xh = xslt_create();
$output = xslt_process($xh, 'arg:xml', 'arg:xsl', NULL,
array(
'xml' => $xml,
'xsl' => $xsl));
echo $output; // print output
?>

ASP.NET

A similar approach to the above is taken, and without wasting time, here is the code:

<%@Import Namespace="System.Xml"%>
<%@Import Namespace="System.Xml.Xsl"%>
&ltscript language="C#" runat="server">
void Page_Load(object sender, System.EventArgs e) {
XmlDocument doc = new XmlDocument();
doc.Load("http://www.cmsproducer.com/labs/xmlpagemarkup/wan_specials.xml");
XslTransform trans = new XslTransform();
trans.Load("http://www.cmsproducer.com/labs/xmlpagemarkup/myspecials.xsl");
xslTransform.Document = doc;
xslTransform.Transform = trans;
}
</script>
&ltasp:Xml ID="xslTransform" Runat="server">
</asp:Xml>

Classic ASP

The Microsoft server object - Microsoft.XMLHTTP is used on the server to accessXML data from a remote location for processing. More information about this server-side object can be obtained at the Microsoft Support resource for Microsoft.XMLHTTP

<%
'Create variable containers
Dim xmlhttp_id
Dim responseXML_id
Dim XMLloaderror_id

Set xmlhttp_id = Server.CreateObject("Microsoft.XMLHTTP") 'Initialise an instance of the MS XMLHTTP object

'Retrieve XML data from a remove HTTP resouce using MS XMLHTTP object
xmlhttp_id.Open "GET", "http://cmsproducer.com/taxonomy/term/91/all/feed", false
xmlhttp_id.Send("")

'Set a condition to see if the data was retrieved by looking for HTTP header status code (200 = OK)
If xmlhttp_id.Status = 200 Then
Set responseXML_id = xmlhttp_id.ResponseXML 'Save the retrieved XML to an object
XMLloaderror_id = False
Else
Response.Write("<p class=""service_alerts"">Page Error: Remote XML resource could not be reached</p>") 'Show error message
XMLloaderror_id = True
End If

Set xmlhttp_id = nothing 'Clear Microsoft XMLHTTP object (important for reuse of resources)

If Not XMLloaderror_id Then

'Load the XML from the responseXML_id object
set oXML_id = Server.CreateObject("Microsoft.XMLDOM")
oXML_id.Async = false
oXML_id.Load(responseXML_id)

'Load the XSL from disk
set oXSL_id = Server.CreateObject("Microsoft.XMLDOM")
oXSL_id.Async = False
'Refer to the XSLT file transform your remote XML resource data
oXSL_il.Load(Server.MapPath("/content/xslt/prepareXHTML.xslt"))

Response.Write(oXML_id.transformNode(oXSL_id)) 'Transform the XML using the XSLT stylesheet

End If

%>

.NET or ASP.NET is touted to be more powerful, versatile and future-compatible that the now archaic ASP server-side programming language. To mention a few, the .NET architecture is built to support XML natively, and it supports more powerful and robust server-side programming languages such as C# and Visual basic in contrast with ASP which mainly supports VBScript which as the name suggests is a non-compiled scripting language.

Migrating from writing simple back-end procedures in ASP using Visual Basic Script (VBScript) or JScript to ASP.NET can prove to be difficult because of the different approaches. Some functionality such as the use of #include to include external static and ASP (dynamic) files has been eliminated altogether in ASP.NET. This is not a limitation to .NET in the bigger picture as the framework/architecture provides for a more powerful and robust approach to building more powerful and robust application, but it can prevent a web developer from quickly #including and re-using.

In this document, we will explore a native ASP.NET approach that can provide benefits similar to those of the #include functionality of classic ASP.

Highlights

1. Uses a method already available in .NET
2. Has the same functionality as #include with the exception that the included file cannot contain dynamic

<!-- END CSS my_hightlights -->

Implementation

The Response object in ASP.NET has a WriteFile method that can be used to directly write the contents of a static file (cannot have dynamic code in it) into the output stream of an aspx.

A more complex approach

Because of the significant difference that is mentioned above (inability to include dynamic content), one my seek a different approach that can indeed provide the same funttionality as the classic ASP #include and more. The following process is outlined in the Microsoft Developer Network simulates include Files with an ASP.NET Server Control. Is more powerful, but also takes more time and knowledge to implement.