"The noblest pleasure is the joy of understanding"   (Leonardo da Vinci)
Website banner

APFCMS - Web Application Framework

The project I am spending my evenings on at the moment is APFCMS, a web application framework that I have been building up from scratch. It is inspired by other frameworks, especially Kohana and Symfony. It also borrows ideas from Drupal.

Basically it will just be a framework, that is, a system where you can install other tools, e.g. a content management system.

I am also simultaneously developing a CMS which can run in the framework, trying to avoid all the errors I see in conventional CMSs like Drupal, WordPress etc.

These are some of the things I am considering:

  • The CMS should allow a designer to build a website “bottom up“. That is, you start with nothing and slowly build your way up to the top, where you have the final working application. Other systems like Drupal, tries to be a general purpose CMS, but fails conceptually, in that it assumes a lot of things about the application you are building. For instance a Drupal contents table contains fields called “body”, “title” and “teaser”. This shows the general paradigm in Drupal that content is usually a posting or a page on the site. But what if you are defining content that do not need three fields? Let’s say you are making a content type (which indeed is possible in Drupal) that should hold only, say, information about a person. Then you do not need a title and a body, instead you might need a field for “first name”, “last name”, “telephone number” etc. In that case you can simply ignore the title and body fields, but in my opinion this is not a clean way. Too much overhead. In APFCMS nothing is assumed about your content. It is possible to extend content with revisioning information, but it is not required.
  • Most CMSs have a very limited set of actions. An action is a general function that can be called anywhere in the system, without having access to a particular instantiation of an object. Drupal’s actions are quite good, but far from optimal (the internal API is messy! They know that, and it is on the official wish list of changes). In APFCMS virtually every function in the system will have an associated action. Furthermore each action has at least two trigger points: One before the action is executed, and one after it has executed. More actions can be defined by the developer.
  • MVC - Model View Controller is a concept where you separate your logic, your data and your view (the presentation). In APFCMS the data part is handled through PHP classes. Each table in a database can be represented as a PHP class, and when an instantation of that class is manipulated, it is reflected in the table.
  • Templates in APFCMS are invoked through calls to PHP classes that handle the reading and rendering of the templates. This way templates can inherit from each other in a natural way. By inheriting your “blog entry” template class from the “master” template class, you will get the structure of the master page (e.g. <head> and <body> fields) and just have to fill out the empty spots in the master page, e.g. where the master has defined that the contents should be placed.
  • Function parameter checking in PHP is not done automatically since PHP is a weakly typed language. So you have to do it yourself; there is no way to directly specify that a parameter must be of, say, type string. You can specify object types but not primitive types or arrays. I have created a class that does a simple type checking of function parameters are, thereby eliminating the need for explicit parameter checking in your functions. In other words, you can always assume that the parameters that are avilable in the body of a function are defined and are of the correct type. An exception is thrown otherwise as it is a developer time error if the wrong number of parameters or parameters with wrong types are passed to a function.
  • APFCMS has a very small core. What this means is that the core consists of only the most basic functions needed to boot up the system, load libraries etc. The rest has been moved into independent libraries. Drupal, being a largely self contained system, has a very large core. This means that you can optimise a lot of things, but at the same time, IMHO, it makes it much harder to make real changes to subsystems. You have to move the whole core into a new revision, which might break compatibility with other systems.

Examples

Here are some code snippets from APFCMS:

Hooking your own function up to an action

function onGetNode($action)
{
  if ($action->State == "before")
  {
    if ($action->params['nodeId'] == 3)
      $action->params['nodeId'] = 4;
    else if ($action->params['nodeId'] == 5)
      $action->cancel = true;
  }
}

Actions::registerHook(”node.get”, “onGetNode”);

What this code does is that it declares a function (onGetNode) which will be called when the node.get action occurs. If the state is before (it means that the parameters are ready, but the node data has not yet been retrieved from the database) then the nodeId will be changed to 4 if it is 3. If the nodeId is 5, the action will be cancelled and no node data retrieved.

What happens is that everywhere in the CMS where nodes are shown, the data from node 4 will be shown when node 3 is requested.

Other application frameworks

Major - PHP based

  • Zend
  • Symfony
  • Kohana
  • CakePHP
  • Solar
  • YAWP
  • Code Igniter (not open)
  • ZOOP
  • Prado
  • Akelos

Major - other languages

  • AIR
  • Ruby on Rails

Unknown - PHP based

  • Achievo ATK
  • AjaxAC
  • Horde
  • OpenBiz
  • Seagull
  • Stubbles
  • Qcodo
  • Yellow Duck
[[[ Copyright (C) Thor Asmund 1998-2008 ]]]