Available System Tags
Digest
Cascade Server provides users with additional functionality by implementing proprietary pseudo tags throughout the system.
Concept
Content Region Tags
The content region tag is the most basic and essential pseudo code that Cascade Server provides. This defines regions within templates where content can be inserted in the form of blocks or as the result of a stylesheet acting on a block.
Metadata Region Tags
In a template, it is often beneficial to insert metadata from the current page without having to define a content region, associated block, stylesheet to display the information.
Passthrough Code
Passthrough code sections instructthe interpreter to exclude the enclosed code when the page is being previewed internally. Upon publishing, the contents of these tags will be uncommented and included in the final page.
Technical
Content Region Tags
All templates should include a default region, which is automatically populated with the page content. "DEFAULT", in the example below, may be replaced with any other name to create as many content regions as necessary.
Metadata Region Tags
Cascade allows users to insert metadata from the current page without having to define a content region, associated block, or stylesheet to display the information. Users may accomplish this by using the following metadata tags:
In addition, there are two more tags which are used to produce HTML meta tags in the published document. Use the following tag to produce the standard HTML keyword meta tag (useful for indexing content, and some search engine technologies will also use page keywords for archiving content):
Use the following tag to produce the standard HTML description meta tag (certain search engines use this tag as additional information about a page):
Passthrough Code Section Tags
The passthrough code section is delimited as follows:
When viewing a file or page containing these types of blocks within the CMS, these sections are left untouched unless the asset is a page with serialization type of PDF or RTF (as determined by the Target associated with the page's Template). If the serialization type is PDF or RTF the section is simply stripped from the code.
When publishing a file or page containing these blocks to a location outside the CMS, these sections are rewritten so that the enclosing comments and "#START-CODE"/"#END-CODE" strings are removed. However, when publishing a page with PDF or RTF serialization type, these sections are once again completely removed rather than rewritten.
For example, suppose we wanted to embed the following PHP code in a page:
Wrapping the passthrough code comment tags allows the page to validate as XML:
When viewing this page in the system, this code would remain inside of the comments untouched; and the PHP code will not render (unless a PDF or RTF configuration of a page is viewed, in which case the comments and the code would be removed).
However, upon publishing to a file with serialization type of HTML or XML, the comment tags are stripped out leaving only the valid PHP code:
When publishing to a PDF or RTF file, or viewing a PDF or RTF configuration of the page within the system, the comments and the code would both be stripped out.
Root Code Sections
The second type of code section currently supported in the system is the root code section, which is delimited as follows:
The root code section is used to support code that must be placed at the very beginning of a document (file or page) – for example, an ASP page that requires a processing instruction before the page's DOCTYPE. Because the system does not allow for XML comments before the root element or for DOCTYPE in a Template, such code must be placed inside of a root code section.
The rules for rendering these code sections both inside and outside of the CMS are the same as for the passthrough code section with one notable difference - when publishing to a file or page with serialization type HTML or XML, the comment tags are removed, but the code inside the comments is actually moved to the beginning of the document. This can be useful if, for example, you need to include a page redirect at the top of the page, but you are using a template that does not have a content region defined at the very top.
For example, suppose you have the following .NET template:
Therefore, when a page using this template was published, the ASP instructions would appear before the page's DOCTYPE.
The following root code section tags could be used to create this template in the CMS:
If there were multiple root code sections in a page or file, they would be placed sequentially at the top of the document in the relative order that they appeared.
Additional System (Pseudo) Tags
This tag surrounds content to be displayed outside the system only. It can be used for paths or blocks of code that need to be present upon publishing but not necessarily when viewed within the CMS.
This tag surrounds content to be displayed inside the system only. It can be used for paths or blocks of code that need to be present upon rendering within the system but not necessarily when published (out of the CMS).
This tag specifies a link to a page. By supplying an absolute system path to the page referenced, the system is aware of the link. This is useful in a number of situations: broken link reporting, link rewriting etc.
This tag specifies a link to a file. By supplying an absolute system path to the file referenced, the system is aware of the link. This application is the same as system-asset:page.
This tag is new and applicable to 4.0 and later only. This tag enables the user to specify a reference to an asset in the system. By supplying the path, the CMS will try to match to an existing asset with that path. The matching is performed for files, pages, and symlinks in exactly that order.
This tag is used for embedding images in PDF and RTF file formats. By supplying a path to the tag, the system is able to pass the appropriate image to the FO processor so that it can display in the resulting document.
This tag is used for supplying a link to a different configuration of the specified asset. So, by supplying the asset path and the target associated with one of the configurations belonging to that asset, the CMS will handle the link appropriately and relate to the configuration.
This tag is used to link to a different configuration of the same page (the page containing the tag). By supplying a system-page-output attribute to an “A” tag containing a configuration name or a target name associated with that target, the CMS will link to that particular version of the page. The system-page-output attribute gets replaced by a “HREF” attribute with the correct path.