Build a Drupal style hook system using PHP reflection

The Movico module is a scaffold for building Drupal modules in OOP and MVC. One requirement of the project is a hooking system, similar to Drupals, that uses OOP. The following is how I plan to build such a system using the PHP 5 reflection API.

This code shows how using Reflection makes it easy to create a system that hooks into several Class methods to build a linked menu. This moves two systems that are heavy resource users and overly cached from Drupal and places them into the Movico domain.

To try this out you can download and install the Movico module, place this code in ...movico/_controllers/hooks.class.inc. Then surf to ?q=app/hooks/get_hooks. If you get a access denied page then add this to the mvc.module

Update: Moving to hiveminds.Wordpress.com to get syntaxhighlighting and Linkedin connectivity

function mvc_access($uri){

    $authorize = array(
        'hello' => array('access foo'),
        'hello_log' => array('access baz'),
        'hello_log_view' => array('access foo','access baz'),
        'get_hooks' => array('access foo','access baz'),
    );

...movico/_controllers/hooks.class.inc
======================================

/**
 * Normally the Classes would be in individual files and loaded via an iterator
 *
 *
 * @author Carl McDade
 * @since 2010-02-18
 */
class ConClass1 {

    function hook_output()
    {
        $var[1] = 'link text(1)';
        $var[11] = 'link text(11)';

        return $var;
    }
}

class ConClass2 {

    function hook_output()
    {
        $var[2] = 'link text(2)';

        return $var;
    }
}

class ConClass3 {

    function hook_output()
    {
        $var[3] = 'link text(3)';
        $var[4] = 'link text(4)';

        return $var;
    }
}

class hooks{

    public $hook = 'hook_output';
    public $arr = array();

    function _modules()
    {
        $vars = array('ConClass1','ConClass2','ConClass3');

        return $vars;
    }

    function get_hooks()
    {
        foreach ($this->_modules() as $module)
        {
            $Class = new ReflectionClass($module);
            $Method = new ReflectionMethod($Class->getName(), $this->hook);

            if ($Method->isStatic())
            {
                $output = $Method->invoke(NULL);
            }
            else{
                
                $instance = $Class->newInstance();
                $this->arr = array_merge($this->arr, $Method->invoke($instance));
            }
        }

        return mvc_view('default', $variables, implode('',$this->arr));
    }
}

?>

Building modules for Drupal using MVC and OOP

I just spent the last day or so working on a scaffolding module that lets developers build a Model-View-Controller application as a module in Drupal 6. The code and ideas are still in beta stages but working beautifully. This is the fleshing out of ideas that came about under development of Drupal websites.

Take me straight to the code

In the last few weeks I have been using only third party modules to build a number of sites in Drupal 6. During this I saw a problem with the present state of coding for Drupal. It has become like the Wild West making it almost impossible to understand any of the thinking, reasoning and organization of the code in any large module. Typically you will find modules that are just so much spagetti code without any documentation explaining what is what and where to find it.


When procedural code fails in its implementation of OOP developers turn to helper modules. Helper modules are performance killers. They act as a pseudo form of a Class to subclass system but lack the functionality of OOP Abstracts, Interfaces etc. Polymorphism is only available while using active modules which leads to a performance hit with each module activated.

Caching is a fix for the burden of loading dozens of modules at runtime and the performance hit experienced under a heavy number of user requests per second. Drupals menu system contains access control and url routing making them subject to unwanted caching and the constant emptying of the menu cache. This hinders the development of on the fly access control and has other unwanted after effects.

The template system for the application layer for modules is dependent on the presentation layer of the entire website. This means that modules developed using template.php in a theme cannot be easily moved without taking template.php and possibly dozens of template files with them. The caching of theme templates hinders development while tools like devel module exist they tend to be crutches rather than solutions to the problem.

What is Movico?

What the Movico (MVC) module does is act as a connector and wrapper for an organized OOP application using the popular MVC design pattern. Six tersely coded functions let the web developer build software in Drupal using PHP object oriented features, recognizable design patterns and Classes for structure. Many of the problems encountered by using typical practices in Drupal module development are removed through the careful use of OOP structures and design. The organization, cataloging of functionality and documentation become easier. Placing as either a Model, View or Controller along with proper designation of code part as Classes, subclasses and methods makes for better code readability. Long term maintenance and upgrading to future version of Drupal are made easier with removal unneeded use of core functionality. One of the best things about building a module like this is that it becomes more of an autonomous or "third party" web application. This makes it quite simple to remove Drupals hooks from the application and move it to another environment or make it a self-reliable web app. This is why the Movico module will always only contain the bare minimum of code necessary to make the underlying application work. A developer will never feel as though it is too much trouble to yank the Movico module dump Drupal and go it alone.


Benefits:

▪ Speedy development using OOP and MVC letting developers use those same skills and knowledge in Drupal and cross to other PHP projects designed in OOP.
▪ Simplicity and organization of code using object oriented design.
▪ True dynamic access control without the need for menu cache refreshing.
▪ A faster more dynamic and autonomous template system for modules. Create templates and variables that are free of theme templates and template.php files. Removes the need to refresh the theme registry cache.
▪ More scalability without after effects.
▪ Easier to add third-party solutions that use OOP design.



Future plans:

Simple test unit testing examples



Summary:

▪ Drupal emulates MVC Helper modules are used as controllers for groups of included files which act as models. Includes are a typical fix for heavy page loads due to reams of code that are used only partially on any page request.

▪ Polymorphism in Drupal is only available using active modules and hooking which leads to significant performance hits in large community websites.

▪ While it is possible to do a "Drupal way" or procedural coded implementation of MVC it is not easy and maintenance becomes a nightmare. MVC this way does not make use of PHP OOP tools which make organization and maintenance easier.

▪ API popularity is a reaction to the lack of the use OOP tools provided by PHP. Heavy maintenance and design of any API can out weigh any benefits provided.

Download from Github

MySQL: Exporting and Importing Stored Procedures

One of my favorite pastimes is eavesdropping on programmers and developers while riding the commuter trains. You'd be amazed at the stuff I hear. Some good ideas are being bandied about but some of them are obviously wrong in thinking or in their research. I became privy to a conversation while over hearing three young professionals discuss PHP and MySQL. It caught my attention because the usual topics are discussed surrounding java or .net. This time a critical decision was made based on errant information. They decided not to use MySQL because it did stored procedures but they would have to be written over and over again. It seems that they did not know that you can in fact export Stored Procedures and Triggers. Having come from SQL Server this was one of the first things I looked for when SPs and Triggers became available in MySQL.

Since version 5 MySQL has stored procedures and triggers. You can backup and restore these function using mysqldump. Mysqldump will by default run all the triggers but leave SPs behind. You can fix this by setting the proper parameters when doing the dump. If you add the --routines command line parameter then you are set:

mysqldump mydatabase -u -p --routines > backup.sql

If you have already backed up everything and are just now reading this. You can grab your SPs with:

mysqldump --routines --no-create-info --no-data --no-create-db --skip-opt mydatabase > spbackup.sql

Run the script like normal to restore to the new db:

mysql mynewdatabase < spbackup.sql

This make me wonder why more CMS systems do not use SPs and Triggers rather than creating copies of these functions in PHP.

Coding Drupal 7 2009-02-08

Okay, so there's a few reviews of Drupal 7 turning up online. They give Drupal 7 look of kudos and praise for the most part. But what these reviews don't do is go into the code. I am going to do that here in the next few weeks as I build Drupal.se using Drupal 7.

Now I am not going to write about bugs unless it is absolutely necessary as part of an explanation of the work. Drupal 7 is in alpha so bugs are expected. What I am going to be doing is talking about the internals that will be of concern to a web developer, php programmer or web designer.

First a bit about the environment. I am running Drupal 7 on:

YAWS webserver
PHP 5.3.1
MySQL 5
Windows 2003 Server

Some things will change as I go through like the use of Clean Urls will be introduced after I decide on using appmods as versus a single arg_rewrite module for YAWS. I may also go with PostgreSql over MySQL later on.

The information will be in short paragraphs without any long articles. The following is an example.

I found out today that Drupal 7 has much more default templating in the core. Upon seeing an extra link appearing in my theme just above the header I investigated the core to find out why this was happening. This lead me to the system module and all of its files. Errant code was to be found in html.tpl.php. I was surprised to find dozens of extra files in the same directory. It seems these are the glue that hold together the default look of Drupal 7. If you are an old timer with Drupal then you probably are familiar with drupal.css. Drupal.css was the bane to all web designers because it needed to be overriden or removed when creating a new design for a Drupal installation. Well drupal.css now has dozens of companion files that will further complicate the learning curve. Hopefully you may never have the need to touch these files in later versions of Drupal 7 but as of now you need to make yourself familiar with them in case you run into the same problems that I am having.

So get ready for some long nights in reading core code if you want to become a true guru of Drupal 7 or make it do your bidding as a web designer.

Drupal scalability and port numbers

I need lto run Drupal on several webservers on the same network and use some different ports of the same host name. This morning I found the Drupal 6 installer does not have support for non-default HTTP port numbers. While trying to do an install on one machine the installer refused to function because the host name was incorrect. Even after trying to force the issue by using the $base_url variable the port numbers were removed and the installation failed.

So I created an installation on another machine using port 80 and then moved the files over to the other. I then found that language settings were being ignored when a non-default port number is used. Changing the port number using the same host name causes the language to switch.

I hope that this gets fixed in Drupal 7.

Drupal Scalability

I received this case study in my inbox from Linkedin.com written Acquia, the Drupal company. While I appreciate the effort to keep me informed I could not help but to immediately take issue with the content and how it is flavored. There is a distinct sprinkling of Drupal throughout the text but it really only skims the surface. It needs more meat.

The scalability solutions mentioned are MySql and PHP oriented and any problems in implementing those solutions using Drupal architecture should be brought to light.

If you want to know what's involved in getting Drupal up to par in this game then read these posts. They are the needed supplements to the paper.

Scale Cheaply

Database Sharding

Drupal.se 2009-02-04

Spent a good amount of time talking to the Tax authorities today concerning Drupal.se as an association and as a hobby. The clarifications give good promise for a non-profit community site. According to the law there is nothing wrong with taking sponsorship advertisements as long as they are reported when reaching a certain level of income. These levels are fairly decent and will allow for Drupal.se to be self-sustaining at some point. There are also provisions for my out of pocket expenses. So I will be drawing up some specs for sponsor advertising and making provisions for donations to the Drupal Association if and when Drupal.se goes over the levels of income needed to sustain itself.

What this means is that the playing field for input to the community by business will be equal. There will be no need for a business to contribute things like web hosting which would give an unfair advantage to a single company.

I have also received some good ideas for Drupal.se from Linkedin and emails at Drupal.org. Some of them may take time to implement but they are not difficult otherwise.

I will not be attending the Drupal meeting in Gothenburg as it will take place during the work week. I am all for short work weeks but not when they start with a Monday.