this is not a blog

I Reckon This Must be the Place, I Reckon

Details of the architecture

Data/Code Separation

We like the idea of Decoupling Content Management, and that is something we have been trying to do, but this is not fully there yet. Our path is also very different than the other approaches to the decoupling.

A few graphics for the basic picture may help. The Monolithic approach:

Content
Management
System
Database

and the Decoupled:

Web Editing Tool
Web Framework
Content Repository

We have been calling it "Data/Code Separation". We look at representation of content solely at the content level. And all we want to manipulate content — write it, save it, view it — is an API. And the API should know nothing about the content.

Our approach to a Content Repository has been along the lines of file_put_contents() file_get_contents(). Which is exactly what our File Mode code uses. There is "on top of that" a directory structure and a naming convention — and that's it.

For MySQL Mode the database is simply an INT and a MEDIUMTEXT to achieve the near exact equivalent of file_put_contents() file_get_contents(). The repository API knows nothing about the data.

We chose a named field document format:

        title:Title
        date:March 1, 2014
    
        I like plankton.

Our approach to the Web Framework part has also been along the lines of an API that knows nothing about the data and there is one basic API: display_contents().

There is though, the data. The data is made up of named fields in a PHP array format:

        $data['title'] = 'Title';
        $data['date'] = 'March 1, 2014';
        $data['body'] = 'I like plankton.';

And the Representation, the "view", is a true HTML template:

        <div>
        <h1>{$data['title']}</h1>
        <div>{$data['date']}</div>
        <div>{$data['body']}</div>
        </div>

Nothing like RDFa is used as we want to reduce data as much as possible. In a way, the HTML too knows nothing about the data as the HTML is just a template. The presentation API is barely more than a print statement.

And the code? Each API is only a few hundred lines long.

And the goal? Truly reusable APIs that anyone can use for any PHP application in only hundreds of lines of code.

  1. This is not distributed scaling, except that it is as far as file_put_contents() and file_get_contents() are.
  2. And a file_delete_contents().
  3. Actually not the name used but that fits in this discussion.