I’ve been working with Apache Couch DB for several months, and have developed a method for templating and html storage that negates the need for actual html to be written (in many cases) and can enforce permissions and fine graned field visibility. This method relies on a scripting language (php in this case) and a few newer functions (php 5.3.x) that use an overloaded html element/tag generator inside a dozen-line static class.
We have a blog. Blogs have pretty much the same stuff, field for ‘post’ content, publisher,summary, etc.
// JSON Record (from couch)
{
"_id": "post_example",
"_rev": "1-6122fbacd408d8700611570143d3f207",
"post_title": "a title",
"category": "",
"post_type": "post",
"content": "Here is an amazing blog post.",
"publisher": "me",
"summary": "",
"status": "published"
}
Here is a ‘template’ array structure, this could be stored and converted from a json object as well.
// PHP Container
$container =
array('head' =>
array('link__stylesheet'=>'main.css') ,
'body'=>
array('div__page'=>
array('div__post' =>
array( 'post_title'=> 'h2__' ,
'category'=>'h3__',
'publisher'=>'h4__',
'content' => 'div__',
'thumbnail_image'=> 'img__',
'post_tags' => 'div__'
)
)
)
);
The function looks at the array key value for a ‘__’, and then generates html based on that specific key name. If the value does not have ‘__’ then it is assumed to be similar to a value in the object ($this) and then uses that value of that key (without the double underscore) as the ‘html’ generation class and the value of the $this as its value.
// 'load_template' php function, that dynamically calls overloaded
// html 'generation' static classfunction load_template($array,$key=false){
if(is_array($array)){
if(strpos($key,'__')){
// Handles iterative operations to properly generate the nested
// HTML (when structured appropriately) for valid values..
// I.e. reduces structures like body->page->post->post_title
// body->page = string(post,post_title);
$html_call = $key;
$r = $this->load_template($array);
foreach($r as $iField=>$iValue){
if($iValue != '')
$r2[$key] .= $iValue;
}
return htmler::$key(implode($r2));
}
foreach($array as $key2=>$array2){
$r[$key2] = $this->load_template($array2,$key2) ;
}
}
elseif($key !=false && $this->$key != false){
// get ready for htmler structure, which will set the field name to the
// could accept another parameter to determine how the field name is
// used within the created htmler structure return HTML ?? paired with
//the object's key value as a return param ??
$html_call = "$array"."$key";
return htmler::$html_call($this->$key);
}elseif(is_string($array) && strpos($key,'__') ){
$html_call = $key;
return htmler::$html_call($array);
}
return $r;
}
Advantages
Smaller json objects, so faster throughput all around. In CMS environments editors can be made to help avoid common html markup mistakes. HTML knowledge isn’t required – and can easily be abstracted to use whatever concept the developer desires (blocks,widgets,sections) while implementing their container of choice (div,ul,li). This becomes more useful when dealing with mobile-based browser web-apps, or when implementing js/mobile frameworks like jqTouch; instead of rewriting an application one may simply modify its containers and/or ’editor’ class.
Scripting languages can effectively (under a default localhost restricted installation, or where passwords are required) act as a gate keeper of data restricting fields to specific users/groups (or entire records), either through the container or a session.
Control is handled primarily through calling the object as a method and passing it a directive, or loading a container when creating the object (or in many cases both)
Containers are easily cacheable and retrievable via APC or memcached, both the container and class can also be stored and converted back from json
The code base is usually very small, (and in my personal php (5.3.x) testing pages would load in normally under 1 meg) at around 20-60ms.
Complications
Storing html directly in json records is still entirely possible; with a multiuser cms this may be very likely, unless
values are parsed for markup. I do not really see this as a huge disadvantage. Most html code lies in markup containers and head values. By ‘forcing’ a designer to work in ‘containers’ we are actually doing them a favor. In the end the developer is in charge of how a designer might interface with the CMS; the developer is left to handle the big questions.. embedded html or an advanced interface that generates the needed json/array structures to avoid it.
Where from here?
In future articles I will talk about my other couchdb related libraries that handle a session cookie (couchCookie), caching (couchCache) and html form generator (poform).