liveSTORYBOARD CMS Brief Technical Overview
Can you provide some techical details on the liveSTORYBOARD CMS?
We have stayed away from too many technical details on our site because making sure sound content management technology choices are made is part of the service we provide.
The following brief technical overview is not meant as a comprehensive guide to liveSTORYBOARD CMS, it is an attempt to anticipate potential common questions we usually get from fellow developers on new projects. Please feel free to get in touch for further details.
Table of Contents:
liveSTORYBOARD CMS is a web content management and publishing framework. liveSTORYBOARD CMS can be categorized as Java WCM Application, that processes XML/XSLT to create and generate (X)HTML pages, print friendly versions, Atom and RSS newsfeeds, runtime-dynamic pages like JSP and Velocity (currently supported), and more.
liveSTORYBOARD CMS is suitable for websites, blogs, documentation systems, intranets, extranets, eBooks, eCommerce, etc.
By default, liveSTORYBOARD CMS comes with everything needed to create such projects - schemas, templates (layouts, navigation schemes, components such as TOC, index, etc.), CSS.
liveSTORYBOARD CMS stores content in a single-source XML repository. Different content types can be used in a project for fine-grained content control and rich semantics. A number of content Schemas are provided, including article, FAQ, blog entry, hCard, FOAF, event, job post, news item, etc. Any content schema (XML Schema or RNG) can be used, but not required. Schemas are provided and can be overriden.
liveSTORYBOARD CMS Customization
As the system provides default configurations and templates, more often than not, liveSTORYBOARD CMS users simply modify the CSS and (X)HTML snippets to produce new sites. The methodology we recommend is to use the XSL to create the XHTML structure, then further style it through CSS.
Developers familiar with XSLT can further customize most aspects of the CMS (see How it works/Customizing for more info). liveSTORYBOARD CMS's web interface is targeted towards easy content creation and updates and site configuration. We do not provide online XSLT or CSS editing capabilities because there are so many excellent tools for these tasks (we love Eclipse, TopStyle, but if you are reading this, you probably have preferred tool s of your own anyway.)
liveSTORYBOARD CMS runs on Linux servers to avoid having to pass higher costs of other operating systems licensing to clients. That said, liveSTORYBOARD CMS can also run on Windows.
liveSTORYBOARD CMS instances are hosted at Rackspace (http://www.rackspace.com). In many cases, we host client live sites at Rackspace as well - liveSTORYBOARD Inc. is a Certified Rackspace Solutions Partner. We made this choice a few years back because Rackspace has the highest reputation for dedicated hosting services. Their premium pricing is worth it. Rackspace guarantees 99.999% uptime. Rackspace's 'fanatical support' is simply unmatched, amazing and available 24/7 (we have put them to the test many times :). Visit Rackspace.com for more info on the data centers.
Software Configuration and Credits
In addition to our custom liveSTORYBOARD CMS Java application, we utilize several Open Source packages for different tasks:
Apache's httpd (http://httpd.apache.org/) as the static web server
dom4j (http://www.dom4j.org/) - for XML configuration manipulation
Apache Jakarta Lucene (http://jakarta.apache.org/lucene/docs/index.html) - to index XML documents and configuration for fine grained search capabilities
Apache Ant (http://ant.apache.org/) - for build, deployment and some runtime tasks
Xerces (http://xml.apache.org/xerces2-j/index.html) as the XML parser/validator, also for XInclude
Saxon (http://saxon.sourceforge.net) as the XSL processor mainly because it has the most community support. Note: transformations can occur with other XSL processors such as Xalan
CVS (http://www.cvshome.org/) for version control because of its popularity, and because it has been 'tried and tested'. We are considering moving to Subversion (http://subversion.tigris.org/) in the near future.
The liveSTORYBOARD CMS architecture is scalable through adding hardware (Linux boxes).
Content Backup and Recovery
Any version of any liveSTORYBOARD CMS managed project can be 'checked out' literally in minutes.
Staging and Generation
We stage generations of the project/site for maximum confidence in the live version. At authoring time, a development stage is used (for example, http://dev.domain.com). Optionally, projects can utilize additional stages, such as:
qa.domain.com - a stage to use for quality assurance testing
cert.domain.com - a stage used to place a certified version of the project/site
domain.com - the live version of the site
Authorized and authenticated users generate a site, a folder, page, topic or content piece to the development stage first. liveSTORYBOARD CMS does not perform any changes directly to a live site.
Static assets are synchronized there as well. When ready to promote to another stage or the live site, the site/folder/page is copied to that stage. Live site promotions can either be automated through SCP / FTP or users can grab a .zip of the whole site and promote manually.
Registered users are validated against the MD5 encrypted passwords and placed into a general application-wide group. Further, users are grouped by project (site), according to their current context. Project groups can have fine-grained permissions, from the entire site down to the folder, page, topic or content piece level, as well as specific tasks that can or can not be performed at the different site levels.
Separation of Concerns
We strongly believe that content should be separate from presentation and business logic. With liveSTORYBOARD CMS, content can be assigned at the folder hierarchy level to cascade down to child pages in that folder or content can be assigned to pages. Content is stored in topic and subtopic hierarchies, but can easily be reused in multiple locations. Updates occur in a single source, regardless of multiple uses throughout a project or multiple generation formats. More than one content piece can assigned to a folder/page.
The XML configuration and content is transformed to simple/clean/light (X)HTML that is further styled by CSS. We enable and advocate using table-LESS layouts since, semantically speaking, tables are for tabular data and add unnecessary bandwidth demands for large scale sites when used for presentation. For that .001% of users out there, who are still using Netscape 4x, we strive to implement layouts that degrade gracefully.
The liveSTORYBOARD CMS team strongly believes in open software standards and liveSTORYBOARD CMS is standards based and output is standards compliant. We have used most large Content Management systems (Vignette StoryServer, Interwoven's Teamsite and others) in large scale production situations in our past lives and found that transferring content and templates between systems is usually very painful. Content migration is the most difficult part of a CMS implementation. It is, therefore, one of our primary goals to provide a clean exit strategy for clients, so that they are never "trapped" in our system.
At any time, liveSTORYBOARD CMS clients have access to all raw assets and/or generation(s) and can generate offline, if they wish. Or, the XML can be transformed to meet the needs of another system. We stand out from the competition on this criteria, through our standards based technology choice, and because, even systems with similar, non-proprietary architecture often do not provide true access to all assets.
More about the Server Side of liveSTORYBOARD CMS
We cache XML configurations to achieve a 'database' in memory.
XSL Templates objects (JAXP - http://java.sun.com/xml/jaxp/) are also cached to achieve transformations in the 20-30 millisecond range.
An entire site of, say, 300 pages with 'print friendly' version and external metadata (metadata is stored as Dublin Core (http://dublincore.org/), but can appear in any form) would take approximately 5-10 seconds to generate, depending on current system load.