Dr Darren says: 'Just because I (constructively) criticise some aspects of Drupal core and the module development API does not mean I don't appreciate Drupal and what one can do with it'

There are few CMS platforms that enable one to develop complex and powerful web sites as quickly as Drupal, and almost nothing can match the incredible Views query view/report system, and it deserves for many reasons to be a very popular world-leading CMS web site platform. If I were not a fan of Drupal, I would not bother to create a site like this designed to help improve its module development environment by introducing an object-oriented bridge for Drupal7.

I use daily and deeply appreciate Drupal for what it is and for
what it can already do. I am grateful, and thankful, for Drupal.

But I make not bones about the fact that I - as a staunch fan of model-driven Java/C++ development with graphical Unified Modeling Language (UML) - don't like the way Drupal6 and Drupal7 were coded, and especially the module development API, and that I am disappointed that Drupal8 still does not make more use of true object-orientation, and still makes far too heavy use of structured arrays that are defined only by documented key conventions.

I quite simply do not want other IT professionals I know and IT students to
think that I think that current Drupal7 code is a good example of PHP code.

Because it isn't. For example, repeating "by convention" Drupal array key strings "by hand" dozens of times in a single Drupal code file is not, in any universe, good Don't Repeat Yourself (DRY Principle) coding, it is painfully Write Everything Twice (WET) (because "we enjoy typing") coding. It is just plain wrong, and it easily addressed through object-oriented encapsulation.

And my very object-oriented-PHP-aware NetBeans IDE also thinks there is a problem with the Drupal7 contributed module API, because it can't see the Drupal array key conventions, and I can't use my IDE to prompt on Drupal "by convention" arrays and receive any help (even though there is some support in NetBeans for Drupal hook function signatures) !

Oh, and of course because the Drupal array keys are not encapsulated as properties of classes, the documentation for the array keys is spread all over the place too, like in freestyle descriptions at the top of Drupal function documentation, instead of in per-property documentation that an IDE can prompt on.

PHP now has (and has had for some time) all the object-oriented support needed to fix it; so there are no excuses anymore. And the OOE = Object Oriented Examples = One Of Each module shows exactly how the problem can be addressed; namely encapsulate the arrays in classes, handle them there intelligently, then pass them off to Drupal core via a bridge to the the .module file hooks. And OOE = Object Oriented Examples = One Of Each uses object-oriented page and form controllers so you won't need .module file based validate and submit handler functions ever again, either.

My constructive criticism of some specific aspects of Drupal coding style and its module development API does not mean that I don't appreciate Drupal, the Drupal community, and the efforts of the Drupal contributed module developers. I have used Drupal (free) for many years, for my own web sites and projects, and for a wide range of clients especially in industry, engineering, education and science. At times Drupal has even helped me to feed my family and keep a roof over my head.

As I see it, the main problem with Drupal is not installing it and configuring it or its incredibly rich set of contributed modules, the problem is under the hood, and in the module development API. As far as I am concerned, the coding and API in Drupal6, Drupal7, and still unfortunately Drupal8 (although it is getting better) is, when compared with working with UML-driven Java, about as fun as banging your head continuously against a brick wall: jr-banghead.gif. It needn't be.

This site is dedicated to showing how it can be done better, through the OOE = Object Oriented Examples = One Of Each module, which promotes true object-orientation (and integration of it with the legacy hook system), and Don't Repeat Yourself (DRY Principle) coding instead of Write Everything Twice (WET) (because "we enjoy typing") coding.

I reckon I can developer modules for Drupal7 better using true object-orientation in PHP, and design patterns.
I am not just complaining; I am providing solutions. And I'm even able to represent those
solutions in graphical Unified Modeling Language (UML) analysis models of PHP classes !
Visit also