Content Database and Data Model

With Maxscape content and (embedded) software is consistently stored in a rational database, called the content database. Each application server has its own hierarchically structured database instance with a unique name, denoted by its application servers name.

The concept of storing content and code in a database instead of on a file system has more consequences than one might think at first glance. After all, a content database has many advantages compared to a file-system approach. It eases data storage greatly and combines the advantages of a rational database and the power of the SQL language with object-oriented server and application programming. Now, you can define a collection of classes that allow an object-relational view of the content and code stored in the content database.

Imagine a node tree with categories, pages, templates and elements instead of a file system with folders and files. Unlike a directory, a database category may contain content and code elements that can be inherited to subtrees. Pages can be composed of category, template and page elements. Template elements can be imported into pages and page resp. template elements can arbitrarily be nested. Defining a content type, a text language, a version number, any parameter becomes a column/row in a database table.

Hierarchical Content Database

The data model implements a hierarchical view of the content's information structure. Like in a file approach, pages are structured in a hierarchical node tree, whereas database categories compare to folders and pages to files.

File System Node Tree:      Content Database Node Tree:
──────────────────────      ───────────────────────────

+──Document Root            +──Node Tree Root
   +──Files                      +──Root Category Elements
   ...                         +──Pages
   +──Sub Folders              ...
      +──Files                 +──Sub Categories
      ...                           +──Sub Category Elements
      Sub Folders                 +──Pages
      ...                              +──Page Elements
                               ...
                               +──Templates
                                    +──Template Elements
                               ...

Pages are generated from categories, templates, and page elements. Elements may contain plain text, HTML, XML, CSS, Javascript and (embedded) server-side Perl code and can freely be intermixed. Page elements can be invoked within templates elements and vice versa, as it is convenient for the content generation process of a special design.

The database content is accessed via the API of the server's run-time system objects, thus hiding and encapsulating details to application code. The database classes implement the database queries and other required functions. Storing content on the file system is possible, but only recommended for binary files, such as images, audio, video and other media files.

The implementation of such a data model with a rational database is much easier than on a file system structured by directories and where files are the smallest storage units. Accessing an element in a database boils down to a SQL query pointing to the related storage places. Such queries are then hidden within the Maxscape WebServer classes member functions. The content generation engine of the application server's runtime system then takes care of the assignment of the storage location to a client's request and generates the content out of the content database.

Whereas file systems are sorted in a hierarchical manner, rational databases work with n-dimensional tables. To maintain the hierarchical structure of a website, the data model maps the hierarchical view to the application server's content database.

The database approach opens up a whole new world of possibilities and lets us introduce features that are much harder to achieve when using a file system approach.

For example, if you want to inherit a property to a complete site, simply create a root category element, define a variable and let the content generation function import this category element into all pages of the site.

If, for example, you want to make content depending on the language to be displayed, simply add a 'LANGUAGE' column to the database. 'NODE' table. The content generation function can now take care of displaying the text in the chosen language, depending on the CGI variables.

Addressing Content Database Node Locations

The location of a node in the hierarchical node tree is given by its category and name. To address pages of an application server's node tree, the CGI query string variables 'Category' and 'Page' are used.

<scheme>://<FQDN>:<port>/<script path><path info>?<query string>

where: <query string> := Category=<category name>&Page=<page name>

For example, this page is addressed by the following URI:

http://Maxscape.com/?Category=/Profile/Content&Page=Index

HTML:

<a target="_blank" href="?Category=/myCategory&Page=MyPage">Link Text</a>

API method yields the above hyperlink:

my $Hyperlink = $Page->mxsLink (Text => 'Link Text',
                                Category   => '/myCategory',
                                Page       => 'MyPage',
                                Target     => '_blank',);

For example, the location of this page is: This page.

Dynamic Content Generation and Content Decomposition

The run-time system supports the generation of dynamic, personalized content stored in a rational database. This is implemented by using a special data model and a template technique in conjunction with the decomposition of pages into category, template and page elements. The idea is to split a page's content into smaller parts, which can then be reused. Category and page elements can be inserted within template elements and vice versa, as it is convenient for the design of a page. This allows to:

• separate content from layout
• reduce complexity and redundancy
• define generic elements
• reuse already defined elements
• map elements to objects and callbacks
• inherit properties and functions to subtrees
• individualize pages
• support of multiple languages
• ...

The concept of content decomposition is the definition of templates, containing category, template and page elements. The templates reflect the common look and feel, the general layout and the overall design. The elements stored the dynamic content that is evaluated at runtime, given by the state of variables and the objects implementing the element. Within the content generation loop, callbacks can be defined, depending on the element names and attributes.

Sophisticated Template Technique and Web Site Design

The database approach allows for the implementation of a sophisticated template technique. Templates are nodes with the node type 'Template' and are used to implement the layout that is common to several pages, thus separating design from content and reducing the redundancy inherent in HTML coding.

Templates are used to implement layouts or features, which are common to several pages or page parts, thus reducing redundancy and management effort. Global templates may be defined to generalize common properties of a template type. Like pages, templates are composed of elements, which can be inserted into each other. Within elements run-time objects are then called in order to generate dynamic content on-the-fly.

Like pages, templates are composed of elements that can be inserted into each other and can be nested arbitrarily. Within template elements, API functions and methods are then called in order to embed page elements or vice versa.

Templates are grouped into template types. Global templates may be defined, to generalize common properties. A global template for each template type defines elements, variables and scripts that are common to each template of a template type.

The piece of code shown below is stored in a template element. $Page is the object containing the page data and the page, category and template elements of the current page. The $Page->ElementContent() method fetches the content of the page elements by their names. Note that the CSS code is inherited from the page category and imported from the page template.

<!doctype html>
<html>
<head>
<title>
  @{[ $Page->ElementContent (Name => 'Title') ]}
</title>
<style type="text/css">
  @{[ $Page->ElementContent (Name => 'Category.CSS', Type => 'parsed') ]}
  @{[ $Page->TemplateContent (Name => 'Template.CSS', Type => 'parsed') ]}
  @{[ $Page->ElementContent (Name => 'Page.CSS') ]}
</style>
</head>
<body>
  @{[ $Page->ElementContent (Name => 'Category.PageHead', Type => 'execute') ]}
  @{[ $Page->UserElementLoop() ]}
  @{[ $Page->ElementContent (Name => 'Category.PageTrailor', Type => 'execute') ]}
</body>
</html>

There are a few things to be mentioned about the above example. Firstly, the code is stored in the content database instead of a file. Secondly, HTML tags and embedded Maxscape method calls are intermixed in the same element's content.

Thirdly, the function call notation might be unusual even for Perl programmers. It is a 'bracketed expression' embedded in a string variable. This construct allows for the execution of Perl code within text strings, as opposed to embedded text strings printed within Perl code. Therefore, it is used as an embedded Perl interpreter for code snippets within text strings stored in the database. The run-time system then fetches the string and executes the code on the fly. Consequently, no additional embedded code interpreter is needed, at least as long as coding permissions don't need to be restricted to application software.

Fourthly, it has to be emphasized that the code is stored in the content database instead of a file. The location is denoted by the template's page and category names. A template has a type and consists of one or more template elements, just like pages do. All templates and pages consist of elements and have describing data attached. An element consists of a name, an attribute and the content. The type of the element content is given by the 'Type' attribute, which can be whatever you have defined beforehand. Defaults are plain text, HTML, embedded Perl, Perl code and Maxscript.

Maxscript is a layer around Maxscape run-time objects to restrict the usage of Perl code within elements.

Element Callbacks

For each element, callbacks may be defined that can be executed on several stages of the page generation process. They can be used to define a layout or trigger an action, for example.

Content Database and WebServer Library API

The object-oriented Maxscape WebServer Library provides an API to access the data stored in the content database, thus hiding and encapsulating details and database queries so that the server and application code do not need to access the database, directly.

Content Database Administration and Management

The configuration, content and software stored in the application server's content databases can be managed via several administration and communication servers with web browser surfaces and some Shell and Perl scripts. Of course, can you use all the database tools, too.