Playing with Headway Themes I’m really enjoying the way it allows me to have rapid theme prototyping in my hands.
Working with it also makes me think of how I could:
- write blocks for Headway using my own in-fieri mVC library
- make my library usage as streamlined as possible
Thinking of a simple framework
My recent discovery of the Inversion of Control pattern made me re-think the adoption of an instance-based framework usage
//file index.php
<?php
$theme = Theme::getInstance()->begin();
$theme->show('FooElement');
$theme->show('BazElement');
$theme->show('BarElement');
$theme->end();
versus the adoption of something more ORMish like
// file index.php
<?php
Theme::begin();
Theme::show('FooElement');
Theme::show('BazElement');
Theme::show('BarElement');
Theme::end();
The problem I had with the latter solution, the static one, was that I did not know where to inject the dependencies the Theme class, really extending the Main class, used; I know now thanks to the IOC pattern.
And what about the lowercase “m” in “mVC”?
Since WordPress comes with such an array of functions that make interacting with the lower level implementation details so easy I really did not see any point in implementing the “Model” part of the MVC pattern thinking that real world implementation of any Controller or View logic would have made ample use of those.
But then I stumbled across Brandon Wamboldt’s WordPress ORM implementation. I like it and I like the idea and really am looking forward to some fiddling and playing around with it.
Decoupling
Another good reason to implement the framework using an ORM implementation is to avoid a strict decoupling to the WordPress ecosystem. Just future-proof thought.