Meet Sitellite's successor: Elefant CMS
A modern PHP framework and content management system based on the improved features of PHP 5.3+. Elefant is an extremely fast and easy to use CMS that inherits all the best of Sitellite, without the fat. Learn more »
Dynamically Switching Templates
What are XT templates?
What does XT stand for?
XT stands for XML Templates, because XT templates are simply XML documents which are a combination of XHTML and specialized XML tags. XT is the template language and rendering engine used by Sitellite to generate web pages for visitors.
What does XT do?
Sitellite uses the XT template engine to compile the different components of the web site user interface together for the web site visitors, including the content, the graphic design, and any programming code required to render a given web page.
0" alt="" border="0" />What is content in a CMS?
Content means any piece of information on the site that conveys particular meaning (ie. the specific subject matter of a page), in contrast to the graphic design, which provides general or relational meaning (ie. web site navigation) and brand reinforcement.
Content types
In Sitellite, there can be any number of content types. Typically, these will include:
- Web Pages
- Web Files (ie. PDFs, Word documents, etc.)
- News Stories
- Event Listings
- Sidebars (ie. lead-ins to other content types)
Template language
XT templates are ordinary XHTML documents with the addition of XT-specific tags that are replaced with actual content by the template engine.
Simple server-side templating language
The need for XT is that XHTML on its own doesn't have the ability to talk to external sources, such as the Sitellite content repository, to retrieve content. So with XHTML, every page has to have the content completely mixed in with the design, or else you have to use some sort of intermediate processor to put the two together on-the-fly.
Traditionally this was done using programming languages such as Perl, Java, or PHP, however these are far too complicated and usually only result in mixing the design with the programming code instead of the content, which is still a problem.
To solve this problem, we created XT, an intermediate language which is much closer to standard XHTML and therefore less complex than a full-blown programming language, but still powerful enough to solve the problem of joining the content with the graphic design of a web site.
Separation of content vs. templates
The traditional method of simply storing each page in HTML format breaks down quickly because the content writers need to either bother themselves with HTML, or need to rely on the graphic designers to actually apply the content changes. This adds an unnecessary step to each and every content change made to a web site.
So the benefit of using a template language such as XT is that by storing your web site content separately from your web site graphic design, you make it possible for the people responsible for each of the two to manage their part themselves.
Where are the templates located?
XT templates live in the "inc/html" sub-folder in any Sitellite installation.
Template sets
Templates are organized into multiple "sets", which typically contain completely separate designs. In this way, the Sitellite CMS user interface can use the same template organization as the rest of the web site, but still have its own graphic design. You can have as many designs for as many applications as you want running on top of the Sitellite platform.
The Template Naming Convention
Inside a template set, templates are stored as individual ".tpl" files that contain the XHTML and XT markup. A single template set can have multiple templates within it, which are organized according to output mode and by template name. The name of the template file is made of three parts: the output mode, the template name, and the tpl extension. For example, the default html template is named html.default.tpl .
Output modes
Output modes allow you to offer different output formats on a web site, instead of just XHTML. This way, you can accommodate different types of visitors as new technologies become available, such as cell phones and PDAs. You can also provide alternative file formats such as PDF output for your web site using output modes. A chapter in this lesson covers output modes more in details.
Multiple templates
Even within the same output mode (ie. XHTML), you may still want some pages to look different than others. For example, your main index page might have more branding and imagery and less content than inside pages, and some inside pages may require more width than others. Sitellite allows you to do this as part of the standard template naming convention.
Templates and CSS
Any good design nowadays contains more than just XHTML, but rather a design consists of two distinct parts. The first, the XHTML, is meant to describe the document moreso than to control the display of it. The second, the CSS, is meant to apply style to the different markup tags in the markup document. In this way, you have even more control over your design, and more meaningful markup (ie. metadata) about your documents as well.
In Sitellite, CSS files live in the template set folders alongside templates. They are considered of equal importance to a complete web site graphic design.
In fact, because XT templates must be valid XML (ie. XHTML instead of HTML), Sitellite actually encourages additional standards compliance that are otherwise not required of most CMS software.
XHTML transitional
XHTML is the newest version of the HTML markup language. The reason for the added "X" is because XHTML is HTML with a few new added rules that allow it to be XML compliant.
XML compliance allows HTML documents to better interoperate with new technologies, as well as other XML-based markup languages, such as Scalable Vector Graphics (SVG), MathML, and XT.
By requiring XHTML compliance in Sitellite's templates, we were able to create the XT template language using only a standard XML parser, which makes template parsing much more stable and predictable.
Directory Layout
The main design templates live in the inc/html folder of your Sitellite installation. Each template set (akin to a theme) lives in a subfolder below inc/html. Each theme has at least three things in it: an html.default.tpl file containing the default template to use for that set, a site.css file containing the styles for that template set, and a "pix" folder for storing related graphics.
Sitellite ships with two built-in template sets, which we recommend you add to instead of modifying: "default", and "admin". The "default" set contains the look of the example web site installed with Sitellite, and the "admin" set contains the design of Sitellite's administrative user interface. These can be a valuable resource in terms of a working example of a template set.
inc/html/
default/
html.default.tpl
site.css
pix/
spacer.gif
admin/
html.default.tpl
site.css
pix/
spacer.gif
In creating a custom design for your Sitellite-based web sites, we recommend you name your template set after the name of the web site (ie. www.yourWebSite.com would use "yourWebSite" as the name of the template set).
Naming Scheme
Where Sitellite's template system gets interesting is in the ability to specify alternate templates within a set. This is done in one of two ways:
Via the "mode" parameter.
Via the page_template() function or "template" page attribute.
The "mode", which defaults to "html", affects the first part of the template name, and is optionally specified via the request URL (ie. ?mode=html). This allows you to provide multiple subsets of a template set based on the mode (aka. content type) that the visitor wants. In this way, you could offer a web site in both HTML format (the default), and WAP format for cell phones, to name one potential use.
The second part of the template name is considered its actual name (the mode could be called a prefix if you like, and ".tpl" is simply a suffix that tells you the file is a template file). The actual name corresponds either to the "template" attribute of the page object (accessible under the "Properties" tab in the page editor, or via the page_template() function inside boxes and actions), to the template attribute of a parent page that is marked as a section root (also under the "Properties" tab), or the name specified in the "default_template" setting in inc/conf/config.ini.php (which you should leave as "default").
This allows you to specify additional templates in the same set that alter the look of specific pages, or of entire sections of your web site.
With all of these naming options, Sitellite's template system offers undoubtedly the most flexible and advanced template selection structure available in any PHP-based system today.
Custom Template Sets
New template sets are installed simply by dropping them into the inc/html folder. To change the default set used by your web site, simply change the "default_template_set" value in inc/conf/config.ini.php to the name of the set you want to be the default.
You can also install additional sets and use them as themes for Sitellite-based apps, which is exactly what we do with the Sitellite UI itself. To do this, simply specify the template set name in your app's access.php files, like this:
sitellite_template_set = myTemplateSet
That's all there is to it. To make your own template sets, simply copy an existing set to a new folder inside inc/html, give it a name, and modify as desired.In addition to being able to edit XT templates directly using any text editor and a browser, or an HTML design tool such as Dreamweaver, you can also edit them directly in Sitellite using the SiteTemplate app. You'll find SiteTemplate under the Control Panel > Tools menu.
Permissions
In order for SiteTemplate to be able to modify your templates, make sure you have your folder permissions set correctly. This is usually done in the Sitellite installation process, but some site administrators skip certain permissions or change them afterwards.
The "inc/html" folder and sub-folders need to have their permissions set to allow the web server to write to them, usually 0777.
SiteTemplate benefits
The benefits of using SiteTemplate instead of an external editor lie mainly in its integration with standards verification services. SiteTemplate has the ability to validate your XML and will require valid XML before it will save your changes, so you never break your site with a template change. SiteTemplate also validates against the following standards at the click of a button:
- XHTML compliance
- CSS compliance
- Web Accessibility Initiative (WAI) compliance
- Section 508 Accessibility compliance
SiteTemplate: Choose a Template
The first screen of SiteTemplate is straightforward. You see the list of available template sets, and you have a link to create an new template set. 0" alt="" border="0" />SiteTemplate: Template Set
When you click on a template set, it gives you the list of the files included into that set: template files for each output modes, style sheets, and images. You can add new templates, style sheets, and images. You can delete items you no longuer need. And you can edit properties of the template set. There is always an HTML template called Default, which cannot be deleted.
SiteTemplate: Template Editor
If you click on a template name, it opens the template editor. This is a standard text editor, similar to Xed editor used elsewhere in Sitellite, but including special functions to help you building your templates.
0" alt="" border="0" />
To begin using the SiteTemplate XT template editor, first open a web browser and log into your Sitellite account on your web site. Next, click on the "Control Panel" option in the Sitellite top bar. From the Control Panel view, select "SiteTemplate" under the "Tools" pane in the top right of the page.
This will bring you to the first screen of the SiteTemplate editor, where you can choose the template set that you would like to modify. When you select a template set, you will see a list of templates, CSS files, and images belonging to that template set.
For the purposes of our examples, let's click the "New Template Set" link and create our own individual template set. You can use your name for the name of your template set. Once you've finished it will take you to your new template set. From here, click on the "HTML > Default" template.
The template editor screen
When you click on a template within a set, you are brought to the template editor screen. This screen contains several features, which include:
- The template name and output mode listed at the top
- The template data itself in a large text area
- A toolbar for inserting frequently used XT tags
- The Save, Preview, and Cancel buttons
- A validation service selector
The default XT template
Looking at any XT template, you can immediately see that it is simply a mixture of XHTML and XT tags. The XT tags are just like the other XHTML tags except that their names all begin with "xt:". This helps keep them distinct for both ourselves as well as the XT template rendering engine.Inserting page elements
From the template editor screen, we can insert any markup we want into the template, as long as it is XML compliant.
Exercice 1
<html> <head> <title>Window Title</title> </head> <body> <h1>Page Title</h1> <p>Page Content</p> </body> </html>
<html> <head> <title xt:content="head_title">Window Title</title> </head> <body> <h1 xt:content="title">Page Title</h1> <span xt:replace="body"> <p>Page Content</p> </span> </body> </html>
Click the "Preview" button again to see your new changes. You should see your original page title, window title, and page content replaced with sample data from the template previewer.
Here we have introduced the main two XT commands, which act as attributes attached to ordinary XHTML tags. These are:
| xt:content | Replaces the contents of the XHTML tag with the specified XT expression. |
| xt:replace | Replaces the entire XHTML tag with the specified XT expression. |
XT expressions
XT expressions are the values placed inside the XT tags. These are what allow you to refer to the page elements such as title, description, and body.The following is a list of some of the main web page properties that can be inserted into your templates:
| id | Page ID |
| title | Page title |
| nav_title | Page title as used in the web site navigation |
| head_title | Page title as used in the top bar of the browser window |
| below_page | The page that the current page is a child of in the web site hierarchy |
| is_section | Whether the page is a section index or not. The properties of a section index, such as the template it uses, are inherited by pages the underneath it |
| template | Which template name is being used for this page |
| include | Whether this page is included in the web site navigation or not |
| keywords | The keywords that have been assigned to the current page |
| description | A description of the current page (ie. for the meta tags) |
| body | The body of the page |
| toc | A table of contents linking to the headers within the body of the current page. This is useful for providing additional navigation within longer pages |
Exercise 2: Using different expressions
Try replacing the title with another field in your template, or adding new tags that reference additional fields.
Substitution
The key feature of all template languages is called "substitution". This is the process whereby the template engine replaces special "tags" throughout a given template with actual data. The tags are like pointers that refer to parts of the data sent to the template. This data can be an array, an object, or any other data type. In XT, there are specific data objects we'll be using. Having the full list of these can help in keeping your requisite knowledge of XT a finite amount.<xt:tpl>
<xt:var name="title" />
</xt:tpl>
If you make this your entire main XT template (named html.default.tpl in your inc/html/test folder), choose 'test' as the default temlate set (in Control Panel > Admin > Site Settings > Default Temlate Set), and you go to http://www.yourWebSite.com/index, you will see the title of the index page displayed alone on the screen. Not very exciting yet, but give it time.Next, we're going to look at other names you can use to refer to the same data value. You can call these aliases -- or perhaps the one we just made is actually an alias of one of the ones just ahead, and it's the real one.
<xt:tpl>
<xt:var name="title" /><br />
<xt:var name="object/title" /><br />
<xt:var name="path: object/title" /><br />
<xt:var name="php: object.title" /><br />
</xt:tpl>
You should now see your index page title displayed four times in a row. This illustrates a few aspects of XTE, the XT Expression language, right off the bat. First is that you can access properties of the default object, named "object", without having to specify the object explicitly. Second is that XTE has at least two modes of interpretation (three in total actually), being "path" and "php", the default of which obviously being "path". Third is that in the php mode, it's not actually syntactically correct PHP code you're writing. This php syntax is called PHP Shorthand, which allows you to get away with leaving out the dollar signs, property/method arrows, quotes, and operator symbols, leaving you with a more readable code-like syntax. This helps avoid the need to refer to objects like this: $object->someValue. The literal "greater than" entity is enough to give me nightmares at least. The PHP Shorthand notation is documented into the XT Reference chapter of this lesson.
<xt:tpl>
<span xt:replace="title">This is a fake title</span>
</xt:tpl>
http://www.yourWebSite.com/inc/html/test/html.default.tplYou should see the string "This is a fake title" where you were seeing the index page title moments ago. View the source of the template, just to see that it in fact hasn't been rendered. This is how Sitellite enables previewability during the design process.
<xt:tpl>
<a href="${site/url}">Phone home</a>
</xt:tpl>
<xt:tpl>
<a
href="http://www.yourWebSite.com/"
xt:attributes="href site/url"
>Phone home</a>
</xt:tpl>
<xt:tpl>
<a
href="${site/url}"
xt:content="site/url"
>http://www.yourWebSite.com/</a>
</xt:tpl>
Inserting boxes
"Box" is a term used in Sitellite to refer to an individual PHP script written using the Sitellite framework. They are called boxes because they are used to output some sort of dynamic functionality that is to be displayed for a web site visitor somewhere on the web site. Examples of boxes include:- Latest headlines
- Upcoming events
- Any web site navigation
Boxes can be embedded into XT templates by using the "xt:box" tag. The syntax for a box is the name of the app that the box belongs to, ie. "news", followed by a forward-slash (/), followed by the name or path to the box. Here are a few examples:
- <xt:box name="news/sidebar"> <xt:box>
- <xt:box name="sitellite/nav/breadcrumb"> <xt:box>
- <xt:box name="sitetracker/bug"> <xt:box>
Exercise 3: Calling boxes
<xt:box name="sitellite/nav/breadcrumb"> <p> <a href="#">Home</a> / <a href="#">Courses</a> / XT Templates </p> </xt:box>
Advanced XT expressions
In addition to the above expressions that simply called aspects of the web page object, there are several different types of expressions. These expressions can be used and combined with the various XT tags to create some really powerful templating features.
The three types of expressions are as follows:
| path | Path expressions are a simplified way of referring to the contents of objects in the XT object register. Path expressions start with the optional prefix "path: " followed by the name of the object, followed by the name of a property of that object. |
| string | String expressions are used to output literal text, called "strings". A string expression starts with the prefix "string: " followed by any string of text. |
| php | A PHP expression starts with the prefix "php: " followed by the PHP expression. |
Understanding expressions is the key to understanding how all of the advanced XT features work.
Path expressions
A path expression looks exactly like how we named boxes in the "xt:box" tag. Some examples include:
- object/id
- site/domain
- cgi/page
- session/username
In each case, the path starts with the object name and ends with some property of that object, separated by a forward-slash. Each of those examples are real paths, referring to objects in the Sitellite CMS by each of those names.
The "object" object is a special case though. The "object" object is the default object being acted upon by the XT template, which in the case of a web page is the web page object itself. So when we said:
<h1 xt:content="title">Page Title</h1>
we were actually saying:
<h1 xt:content="object/title">Page Title</h1>
which, if you remember that paths start with "path: " so that XT knows for sure what type of expression they are, we are actually saying:
<h1 xt:content="path: object/title">Page Title</h1>
But since "object" is the default, and since the default expression type is a path, we can shorten it and keep it simpler and more readable.
String expressions
String expressions are very simple, and on the surface don't appear very powerful or even all that useful, but they can come in quite handy for the simple fact that you can include in them what we call "sub expressions". I'll illustrate this with an example:
<title xt:content="string: Simian Systems - ${head_title}"> </title> Using the "${sub-expression}" syntax, we can actually embed a path expression into the middle of a string expression, allowing us to combine the two to create content that is part static and part dynamic.
Exercise 4: Combining path and string expressions
Experiment with different paths and strings to create new combinations. Try making one that welcomes a user by name.
PHP expressions
Sometimes we need to refer to objects in ways other than by simply referencing their properties. In these cases, we need something more powerful than a path expression, so we use a PHP expression.
PHP expressions actually use a shorthand for the full PHP programming language syntax, which helps make them simpler and more convenient for inclusion in XT templates.
An example of a PHP expression is:
<h1 xt:content="title" xt:condition="php: not empty (object.title)"> Page Title </h1>
Exercise 5: Using PHP expressions
Experiment with different PHP functions that you know of, or look more up at http://www.php.net/, to come up with new possible uses for PHP expressions. Try outputting a PHP expression displaying the current date and time.
Now that we've looked at the raw expressions themselves, let's put them to use.
Simple loops
<ul> <xt:loop through="item php: range (1, 10)"> <li xt:content="loop/item/value">1</li> </xt:loop> </ul>
<ul> <li xt:loop="item php: range (1, 10)"> <span xt:replace="loop/item/value">1</span> </li> </ul>The addition of the "/value" should appear peculiar. The reason for this is that a loop object in XT contains more than simply the value of the current loop item. These additional attributes are referred to by name, as is any other property of an object, and they are:
| Attribute | Description |
|---|---|
| index | The actual index key of the loop item. In cases where you would be looping through named key/value pairs, index would contain the name. |
| number | The numeric index of the loop item, starting at 1 and increasing by 1 each time. |
| length | The number of items in the loop. |
| start | Whether the current item is the first or not. |
| end | Whether the current item is the last or not. |
| value | The loop value in cases where the items being looped through are not objects or arrays. This would be the opposite of index in such cases. |
| even | Whether the index value (not the number) is even or not. |
| odd | Whether the index value (not the number) is odd or not. |
<xt:tpl>
<table border="2">
<xt:loop through="lang intl/languages">
<tr>
<td xt:content="loop/lang/index">en</td>
<td xt:content="loop/lang/name">English</td>
</tr>
</xt:loop>
</table>
</xt:tpl>
Conditional rendering
<h1 xt:content="title" xt:condition="php: not empty (object.title)"> Page Title </h1>
<xt:condition> <xt:if expr="php: session_valid ()"> <p>Welcome, <xt:var name="session/firstname" />, <xt:var name="session/lastname" /> </p> </xt:if> <xt:else> <form action="/index/sitemember-app" method="post"> User: <input type="text" name="username" /><br /> Pass: <input type="password" name="password" /><br /> <input type="submit" value="Enter" /> </form> </xt:else> </xt:condition>
Let's break it down into pieces to see how XT understands it. First, there are <xt:condition></xt:condition> wrapper tags around the entire condition. Full XT conditions require these tags to group a set of <xt:if> <xt:elseif> and <xt:else> tags together to provide multi-condition capabilities. This makes XT very nearly a complete programming language in its own right, together with loops and variables.
Next, we have the <xt:if></xt:if> tag with an expr="" attribute. This attribute calls the Sitellite function session_valid() to determine whether the user is logged in at all or whether they are browsing anonymously. If they are logged in, everything between those tags is shown and the condition exits. When a condition evaluates to true, the entire condition exits, skipping any subsequent or tags below.
The <xt:else> condition would be shown only when none of the above conditions are met. This is essentially a fallback action (ie. "if all else fails, do this"). <xt:else> is optional, in which case often the xt:condition attribute would be a better solution. What the <xt:else> does here is display a form for the anonymous user to log in if they'd like.
Previewing this outside of Sitellite (ie. directly through the browser) will show you the output of all of the conditions. In this way, you can preview the results of each without having to test each condition, visually. Of course, functionally you always want to test each possible condition to ensure that it works as you'd expect.
Multi-lingual text
<xt:intl>Text to translate</xt:intl>
Changing attributes
<p align="left" xt:attributes="align intl/align"> Some text here </p>
<p align="${intl/align}">Some text here</p>
Outputting HTML entities
If you've inserted a or any other HTML entity into your XT templates, you've discovered that it results in a nice "Illegal entity" error. This is because XT templates are XML documents, not HTML documents, and XML parsers know nothing about the special entities, such as , defined in the HTML specification.
In XT, to insert a non-breaking space into a template, you can say:
<ch:nbsp />
XT will translate this into an ordinary in the final web page output. You can use this syntax for any other HTML entity. For example: <ch:copy />, <ch:eacute />.
Exercise 6: Using special characters
Try adding these special character tags to your template to see how they work. Experiment with different entities that you know, or look new ones up here:
Full list of HTML character entities
xmlchar library
Includes
While boxes are the preferred method of inclusion in Sitellite, as they adhere to Sitellite's automatic access control and configuration facilities, I will still document includes here as well, since they can present an elegant, simple, and often powerful solution to certain problems.<xt:tpl>
<xt:inc name="footer.html" type="plain" />
</xt:tpl>
<xt:tpl>
<xt:inc name="footer.html" type="plain">
<p>
This is some temporary text that will be replaced
by the file footer.html when this template is
rendered in Sitellite.
</p>
</xt:inc>
</xt:tpl>
<xt:tpl>
<ul>
<xt:inc
name="http://slashdot.org/index.rss"
type="xml"
item="/rdf:RDF/item">
<li>
<a href="${xml/link}" xt:content="xml/title">Title</a>
<span xt:replace="xml/description">Description</span>
</li>
</xt:inc>
</ul>
</xt:tpl>
<xt:tpl>
<xt:cache scope="application" duration="3600">
<ul>
<xt:inc
name="http://slashdot.org/index.rss"
type="xml"
item="/rdf:RDF/item">
<li>
<a href="${xml/link}" xt:content="xml/title">Title</a>
<span xt:replace="xml/description">Description</span>
</li>
</xt:inc>
</ul>
</xt:cache>
</xt:tpl>
A powerful part of Sitellite's concept of template sets is the modes.php file. The modes.php file allows you to control certain aspects of the different output modes offered by your template set.
An output mode is the file/data type of the content generated by a request to the Sitellite Content Server. For example, ordinary pages on the web are in HTML format, so the default output mode is html. It has a content/mime type of text/html. An alternate output mode might be WML, RSS, or RDF.
Alternate output modes are automatically added to your HTML output in the form of <meta rel="alternate" /> tags in the <head> block. This is done via XT's tag binding feature, which means you don't need any special tags in your HTML document for this to take place.
File Format
; <?php /* [html] content_type = text/html filter 1 = "body: saf.Misc.Search" ;filter 2 = "body: siteglossary.Terms" ; */ ?>
The first and last lines of the file contents are standard INI security measures, which prevent the rest of the file contents from being read by visitors accessing the file directly through a web browser.
The [html] line denotes the start of the html output mode description block. A block ends when a new block starts, or at the end of the file.
The content_type value is the mime type of the output mode, sent to a visitor's browser in the Content-Type HTTP header.
The filter n lines are a numbered list of filters that can be applied to a given field before its output is passed to the XT templates that make up your template set. These can be used to add certain highlighting features to your content, or to format fields that need tweaking for a certain output mode. The field value begins with the name of the field, which can be any of the columns from the sitellite_page database table, or the special field value final which transforms the finished template output, followed by an SAF package name (separated by a colon).
The package references must include a function to transform the field named according to the following rules:
- The SAF path to the package is made lower-case and dots are replaced with underscores.
- The suffix _content_filter is appended to the above.
- The function must accept a single mixed value for the content field being transformed, and return a modified value of the same.
- Alternately, global functions can be specified instead, for example: filter 1 = "body: strip_tags"
Content Filters
<?php
/**
* This is an example filter that inserts a trademark symbol next to
* any occurrence of the name "Sitellite".
*
* @access public
* @param string
* @return string
* @package Myapp
*/
function myapp_example_content_filter ($body) {
return str_replace (
'Sitellite',
'Sitellite<sup>TM</sup>',
$body
);
}
?>
filter 3 = "body: myapp.Example"Now, wherever the name "Sitellite" appears, you should see a trademark symbol. Note that this example was simplified and doesn't consider whether the "Sitellite" name appears inside an HTML tag attribute. For an example that is HTML-aware, take a look at the lib/Terms.php file in the SiteGlossary app.
Creating an Alternate Output Mode: DocBook
<xt:tpl version="1.0"><xt:xmldecl version="1.0" encoding="UTF-8" /> <xt:doctype root="book" access="public" name="-//OASIS//DTD DocBook XML V4.3//EN" uri="http://www.docbook.org/xml/4.3/docbookx.dtd" /> <article> <articleinfo> <title xt:content="head_title">Title</title> <abstract> <para xt:content="description">Description</para> </abstract> </articleinfo> <section> <title xt:content="title">Title</title> <para xt:replace="body">Body</para> </section> </article> </xt:tpl>
<?php
loader_import ('saf.HTML.Messy');
/**
* Converts various HTML tags to their DocBook equivalents. Please note that
* this list is far from complete.
*
* @access public
* @param string
* @return string
* @package Myapp
*/
function myapp_docbook_content_filter ($body) {
$m = new Messy;
$m->transform = array (
'p' => 'para',
'b' => 'strong',
'i' => 'emphasis',
'em' => 'emphasis',
'ul' => 'itemizedlist',
'li' => 'listitem',
'h1' => 'title',
'h2' => 'title',
'h3' => 'title',
'h4' => 'title',
'h5' => 'title',
'h6' => 'title',
);
$body = $m->clean ($body);
$body = strip_tags ($body, '<para><strong><emphasis><itemizedlist><listitem><title>');
return $body;
}
?>
[docbook] content_type = "application/docbook+xml" filter 1 = "body: myapp.DocBook"
http://www.example.com/index/mode.docbook
Another Quick Output Mode: PDF
The PDF output mode is very easy to create, as the function necessary for HTML-to-PDF conversion is somewhat built-in. Sitellite provides a wrapper library in ext.htmldoc around the HTMLDoc HTML-to-PDF command line conversion too, available under a GPL license from:
http://www.htmldoc.org/
tar -zxf htmldoc.tar.gz cd htmldoc ./configure make sudo make install
[pdf] content_type = application/pdf filter 1 = "final: ext.htmldoc"
http://www.example.com/index/mode.pdf
<xt:note>HEADER LEFT "Site Name"</xt:note>As you can see, the modes.php file allows for some powerful control over Sitellite's ability to publish content in multiple formats.
A common whiz-bang feature you'll see on the cool peoples' weblogs is the ability to select the template you'd like to view their site with. While this isn't the most useful feature for most businesses (except perhaps design companies), it's still fun to be able to do. Below I'll outline the steps necessary to add this capability to any Sitellite-based web site.
Caveat: If you've ever browsed through our list of Sitellite-driven web sites, you'll notice that no two Sitellite sites look the same. As such, not all Sitellite templates are created equal, and you'll have to test to be sure the templates you install on your Sitellite-driven site are compatible with one another, and with your content.
Step 1: A template selector
<?php
loader_import ('saf.File.Directory');
$list = array ();
foreach (Dir::fetch ('inc/html') as $set) {
if (strpos ($set, '.') === 0 || $set == 'admin' || $set == 'CVS') {
continue;
}
$list[] = $set;
}
?>
; <?php /* sitellite_access = public sitellite_status = approved sitellite_action = on ; */ ?>
<?php
loader_import ('saf.File.Directory');
$list = array ();
foreach (Dir::fetch ('inc/html') as $set) {
if (strpos ($set, '.') === 0 || $set == 'admin' || $set == 'CVS') {
continue;
}
$name = false;
if (@file_exists ('inc/html/' . $set . '/config.ini.php')) {
// parse the config.ini.php and look for the set_name
// value.
$info = parse_ini_file ('inc/html/'. $set . '/config.ini.php');
if (isset ($info['set_name'])) {
$name = $info['set_name'];
}
}
if ($name == false) {
// if all else fails, make the default folder name
// more presentable.
$name = ucwords (str_replace ('_', ' ', $set));
}
$list[$set] = $name;
}
?>
<?php
loader_import ('saf.File.Directory');
$list = array ();
foreach (Dir::fetch ('inc/html') as $set) {
if (strpos ($set, '.') === 0 || $set == 'admin' || $set == 'CVS') {
continue;
}
$name = false;
if (@file_exists ('inc/html/' . $set . '/config.ini.php')) {
// parse the config.ini.php and look for the set_name
// value.
$info = parse_ini_file ('inc/html/'. $set . '/config.ini.php');
if (isset ($info['set_name'])) {
$name = $info['set_name'];
}
}
if ($name == false) {
// if all else fails, make the default folder name
// more presentable.
$name = ucwords (str_replace ('_', ' ', $set));
}
$list[$set] = $name;
}
echo template_simple ('list.spt', $list);
?>
<ul>
{loop obj}
<li>
<a href="{site/prefix}/index/templateswitcher-select-action?tpl={loop/_key}">
{loop/_value}
</a>
</li>
{end loop}
</ul>
<h2><xt:intl>Select a template</xt:intl></h2> <xt:box name="templateswitcher/list"> <ul> <li><a href="#">Template One</a></li> <li><a href="#">Template Two</a></li> </ul> </xt:box>
Or you can include the selection list in a sidebar with the alias "templateswitcher/list" under the Properties tab.
Step 2: Determining the template to display
The code to determine the template to display should be included on every page request, so we'll want to put it into inc/conf/properties.php, which is a file that is automatically included prior to all page requests for the purpose of declaring application properties or preprocessing instructions. There are several examples already in this file by default. This is the functional equivalent to the conf/properties.php file in each app, except that this one is loaded for all apps and page requests, while the conf/properties.php file for a specific app is only loaded if that app is called.<?php
$template_set = session_get ('template_switcher');
if (! empty ($template_set)) {
page_template_set ($template_set);
}
?>
Let's step through this code briefly:
First we retrieve the session variable 'template_switcher' using the session_get() function defined in saf.Session in the Sitellite Application Framework (SAF), which will contain the name of a specific template set if the visitor has chosen one. Then we check if it's not empty, in which case we know the user has made a selection. If so, we call page_template_set(), which is defined in saf.Misc.Document in SAF, to set the template to the one chosen by the visitor.
Step 3: Writing the template switcher
<?php
session_set ('template_switcher', $parameters['tpl']);
header ('Location: ' . $_SERVER['HTTP_REFERER']);
exit;
?>
That's all there is to it. You should now be able to switch templates on your web site on the fly. Now go install or create some new templates!