While in the process of realizing a new theme for a client and not being in a rush to do it I began thinking about implementing a base of re-usable code for my projects.
Since I already rely, for any plugin I realize, on my Adapter Classes plugin it only comes natural to think about a codebase I can re-use over and over.
WordPress uses templates
I’m not going into details but WordPress uses templates to show the content and expects theme developers to do so.
I try to keep the template count as little as possible and one could, in theory, just implement the index.php file to make a theme. I’m not that lucky when it came to theme implementing but heavy use of template inclusion functions like get_template_part can really keep a well thought theme small in number of templates and template parts keeping the code-base little and easy to maintain. That’s the whole point behind a function like get_header after all: write once and use many times.
MVC
Model-View-Controller is a widely used OOP design pattern that really can keep object responsibilities and relations at bay in larger projects. Quoting Wikipedia
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] Struts, Django, Ruby on Rails, Symfony, Yii, Spring MVC, Stripes, Play, CodeIgniter 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. Struts2,[6]Lift, Tapestry, JBoss Seam, JavaServer Faces, and Wicket are examples of pull-based architectures.
my thought is WordPress is, in reality, a big pull MVC system where views (say templates) make the day. Events like the user requesting a page, and this in turn requesting some hooked actions to happen are the actors and controllers that might render a banner as well as filtering some content really do not know when or by whom will be called.
Many doors and one door
Using a metaphore WordPress is a single door where the sign reads “bedroom, kitchen, dining room, bathroom and anything you want. Really.” where the user knocking and telling where he’d like to go activates the creation of the room from its measures to its furniture; frameworks like Laravel put the user at the centre of a room with many doors, each one stamped with a clear sign like “dining room” or “kitchen” and they come already furnished and ready.
I’m okay with doors but a lamp is a lamp
Keeping to the room metaphore there is no need to create a new lamp each time and using a function like get_template_part will solve the problem brilliantly except that the template code will be a mess of HTML and PHP and I do not like that: I’d like to be able to call a LampController and make it act like an MVC component.
Starting from the end
It all comes down to how much implementing a re-usable framework (invest time) will speed up future WordPress theme development (gain time) and there’s no better point to start than the end to me. Starting tomorrow I will try to build something I will be able to use, in theme development, like this
// file index.php
<?php
Theme::show('head'); // calls wp_head too
Theme::show('headerBanner', array('color' => '#FFF', 'bgImage' => 'unicornsAndRainbows')); // because I like white banner background
Theme::show('sidebar', array('left'));
Theme::show('content', array('titleHeaderSize' => 'h3', 'showExcperpts' => true, 'showRelated' => true, 'coloredReadMore' => true));
Theme::show('contactFooter' , array('mail', 'skype', 'twitter'));
Theme::show('footer', array('color' => '#FFF')); //calls wp_footer too
?>