document title - portsmouth clinical commissioning … boar… · web viewdocument control...

Document Control Address Operations Centre

Bloxham MillBarford RoadBanburyOxfordshire0X15 4FF

Development CentreSitekit HouseBroom PlacePortreeIsle of SkyeIV51 9HL

Document Title document.docDate Created Technical overview specifcationVersion 2.0Document Creator Joseph LyonsDocument Owner Integration DepartmentBusiness DivisionDocument IdentifierPublisher Rights © 2012 Sitekit SolutionsCoverage: If printed, documents are typically useful for three months from

the last modified date. Please check source after this period.

Sitekit TrainingIntegration Training Manual

V2.0

1. Overview............................................................................................................................................................. 3

2. Responsibility as integrator.................................................................................................................................4

3. Understanding Templates within Sitekit CMS.....................................................................................................5

4. Sitekit Proprietary Code......................................................................................................................................6

5. Using Templates within Sitekit CMS...................................................................................................................7

6. Trees, Pages and Inheritance...........................................................................................................................10

7. Configuring and Styling Sitekit CMS Navigation Blocks....................................................................................12

8. Breadcrumb trails..............................................................................................................................................14

9. Global Variables – Why You Should Use Them................................................................................................15

10. Let Editors Easily Manage Links to Pages and Downloads............................................................................16

11. Sitekit Reserved Words (“Magic Words”)........................................................................................................18

12. Sitekit CMS Conditional “If” Statements..........................................................................................................19

13. XML Data Islands and XML Web Services.....................................................................................................20

14. Where to get help and support........................................................................................................................21

_____________________________________________________________________________________________________Sitekit – design guidelines page 2

1. Overview

This document is part the Sitekit CMS Training materials designed to help you use the CMS effectively with your web site, extranet or intranet.

This document covers areas of the CMS such as Templates, Syntax, Modules, Configuration and other areas that integrators using Sitekit CMS should be familiar with.

Because this document covers core principles of Sitekit CMS, it is a useful document for those planning a site or having overall responsibility for a website development project – regardless of language skills.

It is assumed that the reader will have some understanding of what a Content Management System is, why it is needed, and how it differs (and the advantages) over other web site methods such as static pages.

It is also assumed the reader will be familiar with the latest iterations of core markup languages used throughout the CMS such as HTML, XHTML, and XML, and also a knowledge of Cascading Style Sheets.

A knowledge of JavaScript and is also useful, though not critical, unless your particular site makes use of it.

If you wish to integrate features utilizing XML web services, you may also be required to write XSL transform documents. At the time of writing, Sitekit CMS currently supports XSLT version 1.0 and also some eXSLT features. Specific web services are not discussed in this document, however their implementation via XML data islands is covered. Documentation for individual Sitekit CMS web service APIs can be found on the Sitekit extranet.

If you wish to review any of the above disciplines, suggested external online resources are listed below:

General links

W3Schools – a good place to start learning markup languages: http://www.w3schools.com/

Google Code University – basic learning in video form:http://code.google.com/edu/submissions/html-css-javascript/

Sitepoint – useful quick references and printed publications:http://www.sitepoint.com/

Position Is Everything – browser CSS “quirks” explained and demonstrated:http://www.positioniseverything.net/

A List Apart – this article and others demonstrating best practice techniques:http://www.alistapart.com/articles/practicalcss/


http://www.alistapart.com/articles/practicalcss/

http://www.positioniseverything.net/

http://www.sitepoint.com/

http://code.google.com/edu/submissions/html-css-javascript/

http://www.w3schools.com/

2. Responsibility as integrator

Perhaps above all, integrators should be familiar with the role of the editor. One of the key aims for an integrator is to make a site manageable, allow pages to be easily populated and content to be easily edited. Integration that is overly complicated, not “robust”, not efficient and not intuitive is more likely to behave unpredictably and editors may either misuse features or simply avoid using them altogether if they do not find it easy to work with.

Your web site may involve a team of editors and administrators or conversely your job may cover multiple roles where you are acting as both an integrator and editor too. Whatever the makeup of your team, your integration should be able to accommodate editors’ content, and an intuitive implementation will facilitate efficient editing and page population, and ultimately save time for everyone involved.

Please note the term “robust” used above. Specifically this is used with regard to making and styling templates in such a way that they will be able to accommodate editors’ content as above, but to do this for almost any quantity of content entered. As one example, the integrator might consider: “What will happen to this page if an editor uploads an image that is larger than anticipated – will widths be “forced out”, or will content be obfuscated or the image simply be cut off?” or “What if a large quantity of text is added – will background images scale far enough?”

If integrator and editor roles are to be handled by different people, or different teams, then it can be difficult to anticipate what the content of pages will be, particularly the quantity and size of it. Therefore, “robust” integration should allow for this to the greatest degree practicable and in the event that content exceeds it, then it should “fail gracefully” where possible. While editors should be aware of limitations, in reality it is hard to enforce restrictions on what can be done - the CMS does contain features which are capable of this, but potentially it can often hinder editors rather than help them.

In summary, integrators should be familiar with editors and their abilities with regard to the CMS – much of the way the integration is achieved will depend on this factor, alongside future extensibility and possibly anticipating for future redesigns of the site.


3. Understanding Templates within Sitekit CMS

The idea of using templates to build websites is not a new idea. The aim of using templates is to overcome one major weakness of static web pages, where if a feature or style needs to be deployed, or a change needs to be made across a whole site, or selected pages, then it would need to be made individually on every page and would be time-consuming, particularly on large sites – obviously this is not scalable.

Therefore, templates applied to pages pull together elements common to many or all pages of the site so that deployments and changes can be made easily and rapidly in only one place, and to make content independent from markup, and markup independent from style. Most CMS systems today use some sort of template system, and even other systems such as Wordpress also use templates. By separating content from markup, knowledge of markup languages is no longer a requirement for content editors, and therefore a more familiar “word processor” style interface can be used to edit content instead.

Every page in Sitekit CMS has three layers of visible templates that the content of the page will appear in, and be styled by.

It is best practice to keep the number of templates as low as possible to make the site more manageable, and this can be done by careful planning at the design and pre-integration stage in conjunction with advice given in this document. If many templates are used, where each template has only minor differences from another (e.g. just one image that changes from template to template), and perhaps to the extreme that each page is given its own individual template, this really renders the advantage of using templates obsolete. If the minor difference is unique to lots of pages, then it may be that the change should be part of the content of the page rather than the template. It is accepted that there are sometimes individual pages that are radically different from others and will require their own templates, and they may be the only page using them (as an example, typically the homepage will have its own unique templates) but ultimately, the more templates a site has, the more difficult it can be to manage, especially if a re-design of the site is made in the future. By following the advice in this document, and by utilizing Sitekit CMS features properly and fully, template manageability can be achieved.


4. Sitekit Proprietary Code

Much of this document discusses code proprietary to Sitekit CMS. It is not really necessary to learn all such code, as online references and training materials are provided for your reference. However, it is beneficial to recognize the syntax this code usually takes. Almost all Sitekit CMS code in this document is valid XML. It will often take one of the following forms, depending on its application, and some code can work in more than one form:

XML-style tags:

e.g. <COMMENT>CONTENT</COMMENT>, <VARIABLEBLOCK>TITLE</VARIABLEBLOCK>, <ENQUIRYFORM><FORMID>123</FORMID></ENQUIRYFORM>

Sitekit CMS System Variables (also previously referred to as Sitekit “Magic Words”):

e.g. :::date:::, :::thispageinfo.bodylength1:::, :::variableblock-title:::

Sitekit Conditional “If” Statements:

<sitekit:if op1="1" operator="!=" op2="2">YES</sitekit:if>

XML Data Islands:

<xmlconsumer><xmlsource url="http://www.url.net/source.xml” cacheInMin="1000"></xmlsource> <xslsource url="http://clients.gael.net/source.xsl” cacheInMin="36000"></xslsource> </xmlconsumer>

The application of the above syntaxes is discussed throughout this document, but this demonstrates what you should expect to see.

Another important note, is the (X)HTML <head> section of all Sitekit CMS pages. Alongside standard <meta> tags Here you will find much useful information on your site, including the Sitekit CMS Site ID, the unique Shortcut ID of the page you are on, the version of Sitekit CMS your site is running, as well as the name of the Server it is being served from:

<meta name="Sitekit_Version" content="9.5.1.0" /><meta name="Sitekit_siteid" content="2097" /><meta name="Sitekit_locid" content="08j04701u003" /><meta name="Sitekit_ShortcutID" content="7762" /><meta name="Server" content="THWWW16" />

Some of this information may be important to know where to find when integrating your templates, and using some features in Sitekit CMS.


5. Using Templates within Sitekit CMS

Page Layouts

As mentioned, every page in Sitekit CMS is defined by three template layers. The first of these is the outer “Page Layout” sometimes referred to simply as the “Layout”. Page Layouts can be applied site-wide (in “Site Settings”), inherited from a parent page, or applied independently on a page-by-page basis. The default “Page Layout” for a site (if one is not specified) can be set in the “Site Settings” area of Sitekit CMS.

Essentially, the Page Layout is the (X)HTML code directly inside the opening and closing <body> tags of the page. The layout does not actually contain the <BODY> tags – these are entered automatically by the CMS.

The layout will contain the basic outer <div> based structure that is common to the majority of pages on your site. For more information on a why <div> based structure is strongly advised, please refer to the “accessibility” section of this document.

Every tag that opens in the layout should also close in the layout – i.e. you should not have a <div> tag that opens in the Content Layout but closes in the Page Layout.

Page Layouts may also include (but not limited to) elements such as headers, logo, footer, navigation, breadcrumb trails, Sitekit XML data islands, Embedded Forms, Internal, External, Child and Download Links. None of these items are mandatory, and many may also be part of Sitekit Variable Blocks (discussed later). However, every layout must include the Sitekit CMS <COMMENT>CONTENT</COMMENT> element, which is where the chosen Content Layout for the page will appear.

Though only one is required, typically a site will have at least two or three page layouts at least. Often, the homepage of a site may require its own layout due to being substantially different from other pages. Also, module pages may require their own layout due to code placement of the navigation and also as a way of differentiating module pages from standard pages. Modules and module pages are discussed in the “modules” section of this document.


Placement of the navigation element(s) is an important factor to consider. Putting Sitekit Navigation code in the Content Layout instead of the Page Layout is allowed, but will mean an additional layout for modules is required if you wish navigation to appear on those pages, as the module content becomes the content type. Often this happens anyway as the structure of your <div> code can mean that navigation code cannot be put in the layout without breaking the above rule regarding tags only opening and closing in their own template.

Sitekit CMS supports multiple navigations per page – i.e. a “top level horizontal navigation” bar and a “secondary” vertical navigation. These can be styled independently using the ID’s and classes that Sitekit CMS outputs.

Content Layouts

“Content Layouts” are included in every page on your site that is not a module page. They will define the structure of the content on a page, and are included in the chosen layout with the <COMMENT>CONTENT</COMMENT> syntax. They are usually applied on a page-by-page basis, but can also inherit from a parent page.

Content Layouts may include (but not limited to) elements such as navigation, breadcrumb trails, Sitekit XML data islands, Embedded Forms, Internal, External, Child and Download Links.

Content Layouts primarily define where the editable images and text will appear on a page. This is done through the <COMMENT>BODY#</COMMENT> and <COMMENT>PIC#</COMMENT> includes. Tags must be numbered, starting from 1, with a maximum of 99. You may have more PIC than BODY tags, or vice versa – they are numbered independently. Numbers do not need to be consecutive, but you may not skip a number, or have more than one instance of a number. For instance, the following would be valid:

<div><COMMENT>BODY4</COMMENT></div><div><COMMENT>BODY2</COMMENT></div><div><COMMENT>PIC3</COMMENT></div><div><COMMENT>BODY3</COMMENT></div><div><COMMENT>PIC1</COMMENT></div><div><COMMENT>PIC2</COMMENT></div><div><COMMENT>BODY1</COMMENT></div>


Style Sheets

CSS “Style Sheets” are applied to every page on your site. They can be applied on a page-by-page basis, or inherited from a parent page, but are usually applied site-wide in “Site Settings”. Your site may only require one CSS Style Sheet. “Advanced” options for Style Sheets allow you to add a print Style Sheet that is attached to a parent Style Sheet, and will apply when a page is printed using the :::printthispage::: system variable link. Secondary Style Sheets may be included for alternative page styles and colours etc.

Sitekit CMS Style Sheets are essentially the same as standard CSS used throughout the web and do not use any proprietary code as such. They will also include styles for Sitekit CMS modules which provide classes to facilitate styling.


6. Trees, Pages and Inheritance

The main interface in Sitekit CMS uses two trees to display pages and files belonging to your site. The “Navigation Tree” displays only pages. The “Asset Tree” displays files, folders and pages. The structure of the navigation tree reflects the structure of pages as they will appear on the front-end navigation of your site. The structure of the asset tree is independent from the navigation tree – files, folders, and pages are displayed in alphabetical order, and can belong to any other folder on the asset tree. Unlike the Navigation Tree, the Asset Tree also has recycle bin for deleted files, folders and pages. While the structure of the asset tree has no direct bearing on the order of the front-end navigation, the link url’s to pages in the front-end navigation are determined by which folders they belong to on the Asset Tree. Other aspects of the Asset Tree are discussed later.

1 - A Sitekit Navigation Tree with right-click menu expanded on a page

As you can see from the above example, the Navigation Tree has a right click function on each page. This performs such self-explanatory functions as “New”/”Cut”/”Copy”/”Paste”/”Delete” page, “View Live” version of the page, and “Exclude From Navigation” (page is hidden and indicator icon changes). “Rename” the page changes its name in the Navigation, but the Page URL may stay the same.

Order of the Navigation (Tree) is also important as some aspects of pages can be set to inherit from their parent page thereby creating a cascade, allowing aspects to change on just one parent page to affect whole branches of a site. Examples of aspects that can be set to inherit from the parent page are: Page Layouts, Content Layouts, Style Sheets, META Keywords, META Description and Branch Dependant Variable Blocks.

2 - Page Layout and Style Sheet set to “Inherit from parent” page in Advanced tab of Page Properties


7. Configuring and Styling Sitekit CMS Navigation Blocks

Navigation is an important part of any site - logical and intuitive navigation encourages visitors to explore your site, and find information that is relevant to them. Sitekit CMS provides many configuration options for navigation which are documented elsewhere, but this document will help you integrate the navigation with your site and select options that are suitable for your site.

As of Sitekit CMS version 9.2 and higher, there are six navigation types available, however types one to four are now unsupported and purely historical. This falls to whether to use type five or type six navigation – and there are certain circumstances that determine this.

Both types are <div>/<ul>/<li>/<span> based and accessibility friendly. Type six would be the default choice as it is designed to be scalable for large sites, and retains much of the functionality of type five. It’s one limitation is that beyond the first level, pages on the same level with different parent pages are not shown (a.k.a. “cousins”), as well as no pages more than one level below the currently selected page, and therefore by extension, all pages on the site cannot be shown at once using this navigation. This is effectively why the navigation is scalable for larger sites, as loading of a whole site in the navigation adds excessive load time to each page and also server load. Usually only the selected branch of a site is required to be loaded in most cases.

However, there are times when you may be required to load all pages of a site into a navigation, and type five allows this. This might be required, for instance, if you wish to utilize a “drop down” or “pop-out” navigation. Instead of deciding what navigation items are shown or hidden when the navigation loads from the server, pages are set to show/hide in CSS, depending on the classes which allow this. Type five navigation therefore includes many additional classes that type six does not, and can be considered more flexible in how it can be styled, but also more complex.

Example of typical Sitekit CMS Type 6 Navigation XML:Documented here: http://www.sitekit.net/Sitekit-CMS-Help-v9/site-navigation.htm

<sitekit:navigation id=“MENU” class=“menu” />

Unmodified, the above code will produce a navigation of all visible level one pages, plus the selected page and its parents, child pages directly under it, and other (sibling) pages under the same parent page.

Example of typical Sitekit CMS Type 5 Navigation XML:Documented here: http://kb.sitekit.net/Navigation-and-Breadcrumb-Trail/kb2-navigation-xml-configuration.htm

<NAVIGATION><NAVLAYOUTSTYLE>5</NAVLAYOUTSTYLE><STARTLOCID>08j</STARTLOCID><LEVEL>1</LEVEL><ENDLEVEL>6</ENDLEVEL><ID>MENU</ID><MENUITEMIDS>1</MENUITEMIDS><SELECTEDACTIVE>1</SELECTEDACTIVE><NOLOGOUTLINK>0</NOLOGOUTLINK><NOEDITPROFILE>0<NOEDITPROFILE><LISTALLBRANCHES>1</LISTALLBRANCHES><NAVBUTTONCASE>3<NAVBUTTONCASE><SEARCHBOX>0</SEARCHBOX></NAVIGATION>

The above code will produce a navigation of all visible pages on levels 1 to 6 of a site. One important setting to note is the <STARTLOCID> which will change depending on your site – this sets the “root” page for the navigation (usually the home page). The <STARTLOCID> is not mandatory, but is recommended to ensure the navigation behaves predictably. As a reminder, the <STARTLOCID> can be found in the <meta> header tags of any page on Sitekit CMS. Shortcut ID’s do not work in type five navigation.


http://kb.sitekit.net/Navigation-and-Breadcrumb-Trail/kb2-navigation-xml-configuration.htm

http://www.sitekit.net/Sitekit-CMS-Help-v9/site-navigation.htm

Example of typical Type 6 Navigation CSS:You may wish to use the following CSS as a starting point for styling your own navigation:

.menu{display:block;float:left;width:230px;background-color:#EDEDED;}

.menu li, .menu a{display: block; margin:0px;padding:0px;line-height:110%;font-weight:normal;text-decoration:none;color:#000000;}.menu li li {font-size: 0.85em;}.menu li li li {font-size: 100%;}.menu li li li li {font-size: 100%;}.menu li li a {border-top: 1px solid #CCCCCC; display: block; float: left; width: 100%; padding: 8px 0px 8px 0px;}.menu li li .SKNavFirst a,.menu li li li a {border-top: none;}.menu span{display:none;}.menu li li span{display:block;}.menu ul{display:block;float:left;width:230px;list-style-type:none;margin:0px;padding:0px;}.menu ul ul{display:block;float:left;width:230px;padding:14px 14px 8px 14px;}*>.menu ul ul{width:202px;}.menu li li{padding-bottom:6px;}.menu li li a:hover{text-decoration:underline;}.menu ul ul ul{display:block;float:left;width:202px;padding:0px 0px 8px 0px;}.menu li li li{font-size:0.9em;}.menu li li li a{display:block;float:left;width:202px;color:#555555;padding:6px 20px;}*>.menu li li li a{width:162px;}.menu li li li a:hover{text-decoration:none;background-color:#0072C6;color:#FFFFFF;}.menu li li li li a{display:block;float:left;width:202px;color:#555555;padding:6px 40px;}*>.menu li li li li a{width:122px;}.menu li li li li a:hover{text-decoration:none;background-color:#666666!important;color:#FFFFFF!important;}.menu li li.SKNavCurrent a{font-weight:bold;}.menu li li.SKNavCurrent li a{font-weight:normal;}.menu li li li.SKNavCurrent a{background-color:#0072C6;color:#FFFFFF;}.menu li li li.SKNavCurrent li a{background-color:transparent;color:#555555;}.menu li li li li.SKNavCurrent a{background-color:#666666;color:#FFFFFF;}.menu li li li li.SKNavCurrent li a{background-color:transparent;color:#555555;}


8. Breadcrumb trails

A useful feature that is often utilized on sites is the breadcrumb trails. This is a line of links often displayed near the top of the page that lists the current page and its parent pages, thereby showing the user where they are in the structure of the site.

3 - A typical breadcrumb trail with graphical delimiters

Typical Breadcrumb Trail XML in Sitekit CMS:http://kb.sitekit.net/Navigation-and-Breadcrumb-Trail/kb2-breadcrumb-trail-configuration.htm

<BREADCRUMB><LAYOUT>table-less</LAYOUT><DELIMITER>></DELIMITER><NAVDEPTH>6</NAVDEPTH></BREADCRUMB>

The above code will output a <div> based breadcrumb for pages up to level 6.

Example of typical Breadcrumb Trail CSS:You may wish to use the following CSS as a starting point for styling your breadcrumb trail:

.breadcrumb-wrapper div,

.breadcrumb-wrapper a,

.breadcrumb-wrapper span{font-size:100%;line-height:100%;}

.breadcrumb-trail{display:block;float:left;}

.breadcrumb-item{display:block;float:left;}

.breadcrumb-delim{display:block;float:left;color:#0168CB;padding:0px 5px;}

.breadcrumb-wrapper a{text-decoration:none;}

.breadcrumb-wrapper a:hover{text-decoration:underline;}


http://kb.sitekit.net/Navigation-and-Breadcrumb-Trail/kb2-breadcrumb-trail-configuration.htm

9. Global Variables – Why You Should Use Them

Sitekit CMS “Global Variables” are a further aid provided to make your site manageable. They serve as a way to centrally manage elements common to many places on your site, i.e. your site’s logo, a footer, contact details or a phone number that appears in multiple templates.

Sitekit CMS also allows you to set alternate values for a Global Variable if you are on a different branch, or a visiting from a different domain on your site – i.e. a header image that changes across branches, or a country flag that changes with the domain. These variables are referred to as “Branch Dependant Global Variable Schemes” and “Domain Dependant Variable Schemes”.

Sitekit CMS allows you to create your own Global Variable Blocks, sometimes referred to as “User-defined Global Variable Blocks”. However, there are a selected number of pre-existing Global Variables, sometimes called “Reserved Fixed Global Variable Blocks” which control aspects of the CMS such as header and footer code/text for: <COMMENT>DOWNLOAD</COMMENT>, <COMMENT>INTERNAL</COMMENT>, <COMMENT>EXTERNAL</COMMENT>, and <COMMENT>CHILD</COMMENT> links. One of the most important of these blocks is the “HeadSectionHTML” block which controls additional code that can be included in the HTML <head> section of every page on your site, e.g. scripts.

One limitation of Global Variable Blocks is that they cannot contain other Global Variable Blocks. Therefore, Sitekit CMS also provides functionality to extend this ability, simply called “Variables”. These are small snippets of code/text that can be used in the CMS, including in Global Variable Blocks. However, unlike Global Variable Blocks they are limited to 120 characters. The most common use for Sitekit CMS Variables is for telephone numbers, a single image (i.e. logo), address or other short piece of text that may appear in multiple places.

Using Global Variables in Templates and ElsewhereThe syntax for using Sitekit CMS Global Variable Blocks and Variables is as follows:

:::variableblock-NAME:::

This can be used in, among other places: Page Layouts, Content Layouts, BODY blocks, news/events articles, XSLT documents, Image Link URLs, Page <head> sections and opening <body> tag, XML data islands, and also form fields and attributes. Global Variable Block and Variable names may contain letters, numbers, and most characters, but must not contain spaces.

Variables can likewise be referenced in the above ways, but additionally within Global Variable Blocks:

:::variable-NAME:::

There are many useful examples of Global Variables, mostly within Page Layouts and Content Layouts, but one of the advantages of the above code is that it can now be inserted within attributes of tags, not just between them. So for instance, the following is possible:

<a href="web-service-name.xml?APIKey=:::variable-API-KEY:::">Link to the webservice</a>

You may also see Global Variables referenced in a different way, using XML tags: <VARIABLEBLOCK>NAME</VARIABLEBLOCK>. While this is a valid way of referencing Global Variables in certain instances, it is now deprecated due to its more limited use – you should use the above triple colon syntax.


10. Let Editors Easily Manage Links to Pages and Downloads

Sitekit CMS provides easy ways to manage internal and external links, as well as links to download files on your site. Instead of manually linking, and typing out addresses, an interface is provided that allows you to select links from a list or tree. Manual linking would cause problems due to links possibly being mistyped, and also link paths changing when pages and files on your site are moved. Using the provided interface means that links are maintained, even when pages and files on your site (not external links) are moved - the link automatically updates.

4 - Sitekit CMS Asset Picker

These lists of links can be displayed and styled anywhere on a page. To do so, you must include the relevant syntax in either your Page Layout or Content Layout. The syntax is as follows:

For internal links:

<COMMENT>INTERNAL</COMMENT>

For download files from your site:

<COMMENT>DOWNLOAD</COMMENT>

For external links, from the Sitekit CMS link library:

<COMMENT>EXTERNAL</COMMENT>

A list of all direct child pages of the current page can be displayed, activated using the tick box in page properties. This list can be included in your Page Layout or Content Layout using the following syntax:

<COMMENT>CHILD</COMMENT>

Each of the codes included above has a Reserved Global Variable Block above and below the code that appears if links are present or selected.

The process for editors to use these blocks is documented in the Sitekit help files:

Internal links: http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-internal-link.htmDownload links: http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-add-files-to-page.htm External links: http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-external-link.htmChild links: http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-change-title.htm


http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-change-title.htm

http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-external-link.htm

http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-add-files-to-page.htm

http://www.sitekit.net/Sitekit-CMS-Help-v9/help-edit-internal-link.htm

11.Sitekit Reserved Words (“Magic Words”)

Sitekit CMS Reserved Words (sometimes previously referred to as “Magic Words”) are used in many places throughout the CMS: in Page Layouts, Content Layouts, BODY blocks, Global Variables, News/Events, and Forms. They provide auto-generated information related to the page or resource being accessed. The syntax of reserved “magic” words uses a triple-colon style “:::word:::” and some variables may be separated by a period, i.e. “thispage.info.picurl1”. New magic words are added frequently and usually updated with each release of Sitekit CMS. A comprehensive list is maintained in the Sitekit CMS Syntax Guide located in the Sitekit CMS Knowledge Base: http://kb.sitekit.net/

It is difficult to over-emphasize the usefulness of this feature. Some reserved magic words are used almost ubiquitously, such as “:::printthispage:::” to link to the print-version of a page, or “:::textonly:::” to link to the high-contrast text-only version. One common option is to put “<h1>:::title:::</h1>“ at the top of the CONTENT block of a page, thereby automatically generating the main page header from the page’s title in Page Properties instead of it needing to be entered manually.

Some magic words are particularly useful in XML data islands to provide variables to XML web services. “:::uri:::” provides the URL of the current page, “:::domain:::” provides the domain only, and “:::thispage.info. shortcutid:::” provides the Shortcut ID. A recently added magic word that can also be useful in XML data islands is the metadata variable. This can pull the value for a given metadata field chosen in Page Properties, and then used to drive an XML web service, for instance. One example might be to display all other pages that match the category of the current page – in this case you might use a reserved magic word such as “:::metadata.category:::”.

Still, other reserved magic words prove to be useful in <sitekit:if> statements. These are explained in the following section.


http://kb.sitekit.net/

12. Sitekit CMS Conditional “If” Statements

The concept of the “IF” statement is common to many programming languages and follows the BOOLEAN logic of comparing two values. In Sitekit CMS, the values can be compared to see if they equal one another (“=“ or “==“), do not equal one another (“!=“), or if one variable (i.e. a (text) string) is contained within another (“in”), or is not contained within another variable (“not in”). In each of these cases, the result is either TRUE or FALSE.

If the result of the Sitekit CMS “IF” statement is TRUE, then the data or text inside the statement will be displayed, or perhaps allow a <script> to be run. If the statement is FALSE, then the contents of the statement are not displayed or run.

The syntax of Sitekit CMS “IF” statements is as follows, e.g.:

<sitekit:if op1="Variable 1" operator="=" op2="Variable 2">Text to be displayed</sitekit:if>

This feature becomes particularly useful when combined with Sitekit CMS Reserved “Magic” Words. Reserved magic words can be used as variables in the “IF” statement, and used to display, or not display content if the statement is TRUE or FALSE.

Example: using the “picid” reserved magic word, we can show or hide a <div> depending on whether there is an image inside it.

<sitekit:if op1="picid1" operator="!=" op2="0"><div><COMMENT>PIC1</COMMENT></div></sitekit:if>

More examples can be found in the Sitekit CMS syntax document.

Sitekit CMS “IF” statements can be run in Page Layouts, Content Layouts, and Global Variable blocks.


13. XML Data Islands and XML Web Services

“XML Data Islands” are the core method by which Sitekit CMS interacts with XML web services. XML Data Islands combine XML with an XSLT document and outputs the transformation (usually HTML) to the page. The XML Data Island accepts one XML URL and one XSLT URL – these are mandatory. There are also optional settings for caching, POST/GET or SOAP methods, and also restricting what parameters get passed into the XML Data Island.

By default, all POST and GET parameters in a visited page get passed into any XML Data Islands on that page, and therefore, into any XML web service calls in the XML. Additional parameters can also be appended to the XML URL, of course. This means that <form> parameter,s (i.e. a search function) when submitted to a page will also be POSTed to any XML web services in XML Data Islands on the target page.

A typical XML Data Island in Sitekit CMS would look like this:

<xmlconsumer><xmlsource url="http://www.url.net/source.xml" cacheInMin="10"></xmlsource><xslsource url="http://xsl.sitekit.net/source.xsl" cacheInMin="360"></xslsource></xmlconsumer>

One important note is the location of XSLT documents. Due to the volatile nature of XSLT documents, all such documents need to be approved and signed by Sitekit before they can be loaded into Sitekit CMS. XSLT documents are then uploaded to a location on the dedicated site: http://xsl.sitekit.net/. If you are a developer and have an XSLT document for uploading, please submit your document to [email protected] for submission, and mark your email as such, including your site’s name and site ID if possible.

More documentation on using XML Data Islands and Sitekit XML web services API’s is available online.


mailto:[email protected]

http://xsl.sitekit.net/

14.Where to get help and support

Context sensitive help Within the Sitekit CMS control panel you will find help icons linking directly to the associated help information. To find help on any area simply click on the help icon at the top right.

How do I use...? Comprehensive System help: The comprehensive help system can be accessed either directly from the administration system or through this website. It is designed for users of all levels. http://www.sitekit.net/help-v9.htm

How do I build...? Extensive Knowledge Base: Our extensive knowledge base provides technical information suitable for designers, developers, and integrators. http://www.sitekit.net/kb3.htm

Teach me to...? Online Training Materials: All training resources are provided online for participants of a Sitekit Training session. These are currently available as PowerPoint slides and PDFs. http://www.sitekit.net/Sitekit-Academy-Sitekit-CMS-v9.htm

Tell me about Sitekit CMS The corporate website is the best source for up to date information about Sitekit, News, and new products and services. http://www.sitekit.net

Who can I speak to? Call 0845 299 0900 E-mail: [email protected]


mailto:[email protected]

http://www.sitekit.net/

http://www.sitekit.net/Sitekit-Academy-Sitekit-CMS-v9.htm

http://www.sitekit.net/kb3.htm

http://www.sitekit.net/help-v9.htm

document title - portsmouth clinical commissioning … boar… · web viewdocument control...

Documents