CMSity is a content management system that consists of (a) an engine providing CMS API and (b) set of templates that describe final site behavior and functionality.
CMSity does not deal with the files, but with virtual content tree (we will call just a tree). Each tree element (which we will call a node from now on) carries a piece of content (information) and has a name, a type, a position within the tree described by unique address - URL. You may find a similarity between node and filesystem file, content tree and filesystem folders structure, URL and filesystem path, with one exception that a node may be perceived both as a file and a filesystem folder.
Node name, type and position
Lets focus on Bug Reports forum's topic represented by address: http://www.cmsity.com/forum/bugs/welcome-to-bug-reports
We may deduce just from the URL that:
- This topic has a name (WordPress users call it slug) "welcome-to-bug-reports"
- It has a parent being a forum having a name "bugs"
- His parent is being a descendant of forum "forum"
- .. that is descendent of site's root
What is not visible straight from URL is the type of the content represented by this URL and of course the content itself. However in this case we may guess that type will be "topic".
Finally clicking the URL we may see the content presented through some template (we will speak about later) that may carry also some author and date information, and tags. So the primary objective of CMSity is to map a human readable URL to some piece of content and present it to the user. We need to mention that CMSity does the reverse too - maps the content into human readable URL.
Content presentation - introducing templates
Once CMSity finds the content that URL points to, it is supposed to present (render) the content. This is the moment where role of the templates begins. Knowing the type of the node (and action we will mention later), we trigger a template that is responsible for rendering the node's content.
So in case of our "topic" we may define simple template file topic.view.php that will contain:
Note: We use short PHP tags in our examples, if your server does not support short PHP tags, replace all <? with <?php appropriately.
<html> <head> <title> <? p('title') ?> </title> </head> <body> <? p('title', 'h1') ?> <? p('author', 'p.author') ?> <? p('content', 'div#content') ?> </body> </html>
Actions - interacting with content
So we got pretty nice tree of content nodes. But if we think for a while, it would be nice if we could search, tag, delete, and finally create nodes; perform and define various actions.
To achieve this we need to define actions. Well actually every URL triggers some action at CMSity. If do not specify any thing after "?" (in query string) default action is "view", other words empty query string means always "view". That is why our sample file from paragraph above was called topic.view.php. Now if we will try to open URL: http://www.cmsity.com/forum/bugs/welcome-to-bug-reports?delete CMSity will automatically look for the file topic.delete.php, that may look like this:
<? if(t_is('Administrator')) a_delete(); else a_render(403); ?>
So in general if CMSity is about to render a node of type "type" within action "action", it will execute following steps:
- Look for a file:
In case the file does not exists, it will look for a file:
If this file does not exists too it will try:
Finally if that one does not exists it will trigger:
If this one doesn't exists, a fatal error will be risen.
No back-office, editing, deleting done via templates
CMSity does not have a back-office, separate GUI responsible for managing content data like other CMSs i.e. WordPress, MODx. All content edition is done via templates and specialized actions too. CMSity bundle comes with _.edit.php, _.create.php and _.delete.php templates responsible for providing content management forms integrated with site's interface.