Scripting Languages
Digest
Content from the system can be published as files with any desired file extension. For example, from a single content repository, multiple sites can be managed, each with a different scripting language, such as ASP, ASPX, PHP, CFM, SSI, and JSP. The system supports managing content that is published to multiple servers in a non-heterogeneous environment.
Technical
Changing Target Output File Extension
The first step for publishing content with a specific file extension is to modify the publish target.
- Go to the Administration area, and select Targets & Destinations from the left navigation bar.
- Select the desired target from the left navigation bar. In our case, we will choose the /web target.
- Click the Edit tab.
- In the Output File Extension field, type .asp (or a different extension, depending on your needs).
- Click the Submit button to save the updated target.
With a target set to publish files in a designated extension, the next step is to incorporate the appropriate source code include line. Code to include other scripting code can be entered directly in the template or in blocks or stylesheets that are placed in template regions. Includes can even be dynamically written out with XSLT based on input from the user in a data definition or system asset. The benefit is that content from the system can be combined with custom programming to create new opportunities.
Incorporating "Scripting Include" in Template
To modify the template with scripting include code:
- Go to the Home area.
- Browse to a page that uses the desired template. In our case, we will select /web/about.
- On the View tab of the page, click the Configurations pane to view the individual configurations and their corresponding templates.
- With the configurations and their templates displayed, click on the template to be modified. In our case, we will select /web/templates/standard from the HTML configuration.
- Now with the template displayed, click the Edit tab.
- For the XML field, scroll to the very bottom and put in the appropriate include code before the tag. For our ASP example, we will enter:
- Click the Submit button to record the template change.
With the template updated, now you can publish out the content and it will have the appropriate file extension and scripting language includes. Because the scripting language include won’t be processed in the CMS, it is sometimes important to give the CMS user a visual clue that a specific region of content will be different when it is published to the live server. The CMS supports pseudo-tags whereby content is tagged as viewable internally in the CMS or externally when content is published.
System View Internal and External
To incorporate the pseudo-tags for internal and external view, please do the following:- Browse to the appropriate template. In our case, we will select /web/templates/standard.
- Click the Edit tab.
- Scroll to the bottom of the XML field area and just before the body closing tag, type the following:
- Click Submit to record the template changes.
If you browse to a page that uses the template, you’ll see the content at the bottom of the page. When you publish the page, the resulting file won’t have the notice and will have the include for the actual dynamic code.
Server Side Scripting Integration
Introduction
As server-side scripting technologies such as JSP, ASP, .NET, etc. become more prevalent, there is in increased demand for Cascade Server to support embedding of these types of code into published files or pages. The problem is that much of this code would not pass through an XML validator. For example, the JSP tags <% and %> used to evaluate a JSP scriptlet are not valid XML, and could not be directly embedded in an XML/XHTML Block, Template, or Page within the system.
The solution is to embed this code inside specialized XML comments that go through some string processing during the rewrite phase of file and page rendering. These blocks of XML comments will be called "Code Sections." Currently, there are two types of code sections supported in the application: Passthrough Code Sections, and Root Code Sections.
These code sections could be included in any type of asset that eventually makes it into a file or page, because pages and files are the only publishable assets in the system. This means that they could be embedded in a block, template, stylesheet, the default region of a page, or in the text of file.
However, some basic requirements such as maintaining common elements like headers, navigations, and footers, that are handled via a scripting language or server-side include (SSI), can be completely converted over to built-in Cascade Server equivalents and published out as regular XHTML files.
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:
{CODE-7}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.
FAQs
- Does Cascade Server support Server-Side Includes?
- Cascade Server supports the use of server-side includes (SSIs) and can push out the files and necessary includes to the destination servers.