There are many different types of PHP frameworks today, most of them are based on a few key concepts and then move in their own direction from there. Before I really get started, let me first say that the title of this series is misleading; there isn’t going to be a single perfect framework to get us through the 2010’s. This series is mainly on key concepts that may or may not be implemented in various frameworks, although I have yet to see a single framework implement them all. We will also bend the line between a framework and a content management system.

The first concept we’ll be discussing is the Model-View-Controller (MVC) architectural pattern used by the majority of frameworks today. While it is a time-tested concept, it is not without its flaws. I started out as a web developer before I ever learned any scripting languages. Because of my background as a designer, I always preferred a system that favored the designer as much as the programmer. Most occurrences of the MVC pattern make it difficult for the designer to take full control over the presentation of the web site, whether it is overriding a view or breaking the view into separate views. For that reason I prefer a theme-driven pattern, where a central template layer acts as the controller of the MVC pattern and regulates what is displayed.

In Xaraya the central template layer is the Themes module’s page template, which designates which other modules are to be displayed for a given URI (more or less, BlockLayout is a little more complicated than that). In Clay, the template engine is an API class, which takes the URI (whether it is configured or URL driven) and loads the central template layer. Like Xaraya, the central template layer (called the page template), provides the overall presentation of the web page and calls applications to provide data to fill in the page. I may be mistaken, but as someone that tries to follow patterns literally, I find it difficult to implement a theme-driven pattern originating from the classic MVC pattern. (Note: I have since learned how to implement a theme pattern within the MVC pattern, but it feels like a work-around at best.)

The next concept I’d like to mention is the use of core components in frameworks. Most frameworks have a set of components which it can not function without, most often named the ‘Core’. This use of a core originates from the need of CMS’ to have a set of functions to make rules for the overall system. More often than not, the core becomes bloated and the end-developer normally ends up with a ton of extra functionality becoming available, with or without their knowledge of it being loaded. The bloated cores of various frameworks are one of the reasons I began working on Clay.

Clay Framework  doesn’t have a ‘Core’, it only loads what is needed to display the current page. If you say it has to have a core, then fine with me, its core is a single class that allows you to specify the application and template engines, while providing functions to dynamically load any APIs needed by your applications or templates. Clay’s weight grows as you need it, but is never larger than it has to be. I borrowed the architecture from the way an operating system (a decent one) uses libraries to support applications or services, but doesn’t load them automatically without a need to load them. Clay isn’t self-aware, it just loads what you tell it you need and gives it you.

Finally, for Part 1 at least, I would like to mention low-level configuration. Most frameworks have a single configuration method, which provides the system with the information it needs to operate. Some frameworks have no, or very little, required configuration. Xaraya, for instance, includes a config.php file which provides all of its low-level configuration data, such as database connectivity and basic settings. Clay’s ‘Core’, if you insist, takes an array or specified configuration name and initializes based on that data. If you give it an array, you give that configuration a name, which means you can override parts of a named configuration by sending an array specifying the same name.

Clay’s low-level configuration provides default behavior for a page load, such as what theme to use, which application should be loaded (if not otherwise specified), the directory structure, etc. The name of the configuration tells ClayDB (Clay’s database abstraction layer) where to look for database connectivity information, if no database connection is ever requested, Clay will run without it. What all of this means is you can run a server’s load of web sites, each as dependent or independent of one another as you need, from a single Clay file set. Point all of your domains to a single Clay root directory and let your bootstrap file specify what configuration names go with that URL. Most frameworks do seem to be capable of running more than one site from the same file set, as do many CMS’.

To wrap it up so far, a 2010’s framework should have:

• Powerful template system for the web designer
• Dynamic “Core”
• Flexible low-level configuratio

To be continued…