Server side, in depth

In this document we will go through the integral parts of Arlimas system design on the server side. What you will find reading this documentation is that Arlima is a somewhat stand-alone system integrated with WordPress in form of a plugin. This is an intentional design decision, treating portability and modifiability as two highly prioritized quality attributes of the system architecture.

Table of contents

• UML — The overall design of the core system.
• Conceptual model — What is what and how do they all relate to one another
• Object repositories — Managing of CRUD-operations on objects
• List builder — Putting it all together

In addition to this documentation we also have the auto-generated class docs that you can take look at if you really want to dig deep into the code.

UML

Looking at the model below you'll see the design of Arlima at its core. Arlima has two responsibilites on the server side, creation of objects and rendering of lists. Arlima does this with help of the underlying CMS (WordPress) and template engine (Mustache). Arlima never interacts directly with these two helper systems, all is handled via the facades TemplateEngineInterface and CMSInterface

Conceptual model

At a conceptual level you could say that Arlima is a tool for arranging a bunch of articles in a bunch of different lists. You then probably think that these articles is the same as WordPress posts but that is not the case. Arlima has its own article object which is nothing other than a container for data representing something. This "something" might be a post in a WordPress database but it might just as well be an article on an external website, it might even be something totally different like a reference to a PHP-file in the local filesystem that should be executed when the article gets rendered.

In the conceptual model below we try to illustrate some of the entities and how they relate to one another.

Object repositories

Arlima has two repositories that it uses to perform CRUD-operations on objects that is persisted in the data storage provided by the underlying content management system. When wanting to modify any of these objects the repository classes is where you turn to.

When rendering lists, on the other hand, you should turn to the list builder. This class is capable of constructing list objects with certain versions (read more here) and it also has a built in object cache that might improve the performance.

Constructing list objects

To get hold of list objects you can use Arlima_ListBuilder which can be accessed statically via Arlima_List::builder. This class can construct list objects following a set of instructions, it also uses method chaining.

Use either the method id() or slug() to reference a list object.

// Load the latest version of a list (future articles excluded)
$list = Arlima_List::builder()->id(12)->build();
$list = Arlima_List::builder()->slug('my-list')->build();

// Load latest version of a list including future articles
$list = Arlima_List::builder()
              ->id(12)
              ->includeFutureArticles()
              ->build();

// Load a specific version of a list including future articles
$list = Arlima_List::builder()
              ->id(12)
              ->version(1192)
              ->includeFutureArticles()
              ->build();

// Load preview version of a list
$list = Arlima_List::builder()
              ->id(12)
              ->loadPreview()
              ->build();

// Load latest version of a list that is connected to 
// a specific page (excluding future articles)
$list = Arlima_List::builder()
              ->fromPage(341)
              ->build();

// Load external list, including future articles
$list = Arlima_List::builder()
              ->import('http://website.fi/sport/arlima-export/')
              ->includeFutureArticles();
              ->build();

// Load a remote RSS feed
$list = Arlima_List::builder()->import('http://website.de/feed')->build();

Note that you also can use the template function arlima_load_list.