I have decided to use WordPress as my preferred web application framework. This is because it is free, simple, elegant and easily extensible. For this post I though it would be useful to compare it with a general web application framework as described on Wikipedia (displayed in italics below).

Model–view–controller (MVC)[edit]

Many frameworks follow the MVC architectural pattern to separate the data model with business rules from the user interface. This is generally considered a good practice as it modularizes code, promotes code reuse, and allows multiple interfaces to be applied. In web applications, this permits different views to be presented, such as web pages for humans, and web service interfaces for remote applications.

Although WordPress is not architectured to follow a canonical MVC pattern, it does have some separation of concerns. The underlying concepts of posts, menus, widgets, categories and taxonomies are well separated from their presentation by the use of themes. The recent addition of the REST API has added a web service interface.

Push-based vs. pull-based[edit]

Most MVC frameworks follow a push-based architecture also called “action-based”. These frameworks use actions that do the required processing, and then “push” the data to the view layer to render the results.^[5] Django,Ruby on Rails, Symfony, Spring MVC, Stripes, CodeIgniter^[6] are good examples of this architecture. An alternative to this is pull-based architecture, sometimes also called “component-based”. These frameworks start with the view layer, which can then “pull” results from multiple controllers as needed. In this architecture, multiple controllers can be involved with a single view. Lift, Tapestry, JBoss Seam, JavaServer Faces, (µ)Micro, andWicket are examples of pull-based architectures. Play, Struts, RIFE and ZK have support for both push and pull based application controller calls.

This article explains the difference between action-based and component-based MVC frameworks. WordPress is put in context by this Stackoverflow post which suggest that WordPress is a bit like a component-based MVC framework.

WordPress is kinda-sorta MVC. If anything it is a pull-type MVC layout, where the View ‘pulls’ data from the model. It does this in a very procedural way, instead of using lots of different objects, but this actually makes the front end templates easier to write in a lot of ways.

This also gives the views some degree of controller logic (thus the kinda-sorta MVC).

Lets run this down: WordPress gets a URL. The WordPress core acts as a controller and determines what initial queries to run of the database, and by extension, what view should be loaded (category view, single post or page view, etc). It then packages that INITIAL query response and sends it to the view file.

That view file CAN be a strict display only file OR it can request additional information/queries beyond the built in one. This is the pull-type of the MVC, where the view pulls data from the model instead of the controller ‘pushing’ data from the model into the view.

Thus, when the view sees code to load a sidebar or widget area, it asks for that information. However, what widgets should be there is determined by the controller, which looks at the model for what widgets are in the sidebar, and then selects those that are set to show on the current page, and returns those to the view.

That each part of that isn’t an object doesn’t make this any less MVC. You can alter WP core without (necessarily) altering anything about a theme. Similarly, as long as you use built in functions like ‘get_pages()’ then the model and the database tables could change as long as those functions still returned the right data. So, the model is independent of the view, and the controller is independent as well (except when the view adds controller logic to do more than the core normally does).

While you COULD have a model object holding a number of methods and stuff like WPModel::get_pages(‘blah blah’), and contain everything that way, there is still fundamental separation of concerns.

View: template files Controller: WP core Model: the various functions that handle specific data handling.

As long as the names, arguments, etc, stay the same (or just have new ones added) then separation of concerns is maintained and one can be altered without disturbing the others.

It isn’t a super-clean version of MVC, (especially when hooks get involved), but at a basic level it starts there.

And being procedural about it isn’t a bad thing IMO. A request from a website is pretty inherently procedural: it is a process with a clear beginning and end, and just needs a procedure to process the request, get data, package it, then die. You can set up those steps with objects and object methods and OOP layouts (which would make some things easier) or you can just write a lot of function calls and separate them out that way. Class members like private variables are lost that way but depending on the needs of the application… you might not care.

There is no one-grand-way to do development, and WP sits at like 20% of websites so it is doing something right. Probably something to do with not making people have to learn/memorize complex class hierarchies to get the database to answer the question ‘what pages are child of page x?’ and deal with that data. Could you make it that easy with OOP? yes, but if Joomla is any example of how hard it is to implement a complex custom website with OOP, then WP is FAR easier and quicker, and time is money.

Wikipedia also lists key features of a framework.

• Web Template System
  • This is WordPress’ key functionality
• Caching
  • WordPress has built in caching and this can extended by the use of products such as W3 Total Cache
• Security
  • WordPress has degree of role-based security and this is easily extended by the use of plug-ins.
• Database access, mapping and configuration
  • All access to the database is possible through well defined API’s and the core WordPress objects are well known
  • There is no support for database transactions
• Scaffolding
  • This is automatic creation of interfaces to new classes. WordPress does support the concept of Custom Posts. These may usefully be thought-of as new classes and therefore one might say that there is a form of scaffolding
• URL Mapping
  • Support for friendly URLs. This is a key function of WordPress
• Ajax
  • WordPress supports Ajax and the jQuery Javascript library is bundled.
• Web Services
  • WordPress has recently demonstrated a REST API
• Web Resources
  • WordPress has not yet demonstrated any implementations of Resource Orientated Architecture.

It that is an application framework what is an application?

An application is a computer program that enables a user to execute an use case leading to them achieving their goal.

We will see below that the developer using WordPress as her preferred platform will seek to implement the use case by configuration rather than coding. The difference between “Website” and “Application” becomes increasing blurred because WordPress features and common extensions (plug-ins) negate the need to write code.

It can be seen that for many goals, “find out about Napoleon” or “find out about my local school” plain vanilla WordPress is enough. Text, graphics, pages, posts and menus will do the job fine. Most people would not describe these as applications but “websites”.

The next level of sophistication is to have different types of content. WordPress supports Custom Posts which have additional meta-data that can be used to change their presentation.

Greater personalisation can be delivered by having authenticated users. We can now provide personalisation based on the user’s identity and role. This is done by using plug-ins such as BuddyPress or WPMU Dev membership plug-ins (many others exist).

Many applications are transactional and we need to be able to create a form and capture data. Having persisted it we need to be able to update and report on it and read and write to other systems.

I will discuss this in my next post.