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.
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.
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.
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.
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: . 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.
© Copyright 2001 - 2016 Webel IT Australia (ABN: 67 677 268 579). All rights reserved (except as specified below).
PHP code examples from Webel IT Australia on this site are distributed under the GNU General Public License.
Excludes text and code snippets from Drupal.org quoted for educational purposes.
Drupal’s online documentation is © 2000-2014 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0.
PHP code from Drupal.org is distributed under the GNU General Public License.
Drupal® is a registered trademark of Dries Buytaert.
Text quoted from Wikipedia for educational purposes is made available under the Creative Commons Attribution-ShareAlike License.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Site developed by Webel IT Australia.