The prevailing lack in PHP-based Drupal™ CMS of the following technologies (largely perpetuated into Drupal7) drives me (even more) crazy, and it wastes my time:
- substantial object-orientation
- flexible method-based hook encapsulation
- custom type field and user interface inheritance
- use of GoF and other well known design patterns
- support for graphical software engineering technologies
If you are an advanced Drupal user with discerning clients, I can assure you that it is wasting your time and money too (even though the software is "free"), and there are much better, well known, well tested ways that have not yet been embraced by the Drupal.org community.
I want to help fix it, and I clearly think that Drupal™ CMS does need a lot of fixing. I (Dr Darren) am a person who can do that, because I am the developer and promoter of the incredibly powerful «wrapper» Component-based UML™ Parsing Analysis analysis recipe, and also develop a powerful recipe I call "snippet-driven" software and systems engineering, a meta-process for document-driven engineering, and because of my current deep involvement with Drupal™, which runs many sites for me and my clients.
As far as I can tell, not one other Drupal user is using such powerful software engineering technologies in combination with their Drupal coding and documentation, and the DrUML and JUML projects are conceived not only to help me, they are conceived to teach you, and to act as as clear examples of what is possible with advanced software engineering process and strategies. I am an evangelist for technologies not yet embraced by Drupal, and I would be delighted to convert at least some Drupal users and developers. I do think Drupal.org needs some salvation.
If I am going to stay with Drupal™ CMS technology, I am going to have to either help reengineer it (which I hope the DrUML project will help achieve for Drupal8), or, perhaps foolishly, I will have to consider forking completely away (given sufficient support and interest from others) to a new Drupal-friendly Java project, which I've decided to call:
JUML: The Java+UML Content Management System
Pronounced 'joo-em-el', with intonation like 'U-M-L', the name is chosen to also sound a bit like both Drupal and Joomla, although in fact all the document mappings are to be from Drupal.org (only).
The JUML project represents a forked design layer for the DrUML analysis project, i.e., once the analysis layer is sufficiently evolved, executable Java components can be generated from them (against my own Webel Java frameworks, and against the Eclipse Modeling Framework (EMF)).
For now, JUML should remain merely an educational example of snippet-based UML™ Parsing Analysis, however by design, it will be able to interact with Drupal sites (and will provide a Swing or SWT interface to them, too). It is not intended (yet) to completely replace or fork from Drupal, and a fundamental requirement is that it should always (!!!) be able to interact with prevailing Drupal sites (at least with my own).
By contrast, the DrUML analysis project is very ambitious, and I want it to cover large portions of crucial Drupal elements.
Moving to some other open source Java CMS projects is not the answer for me, not least because I run so many Drupal sites, but also because the Drupal community is so strong, and there are things about what I can do with Drupal and some contributed modules that I like (and appreciate). I want to amplify the power of that community.
To do this I need snippet-driven engineering and UML™ Parsing Analysis (which manage the mapping from Drupal docs), and I need Java™, because although I can do some reverse engineering of PHP into UML, it requires too much babysitting because PHP is untyped (although, as I've often pointed out, it would be nice if PHP would at least support type-hint annotations, which could be reverse engineered to graphical UML™, it's easy enough to do).
Best of all: JUML is conceived to be able to write PHP against Drupal module APIs, because (my) Java can write PHP ! The graphical UML-based engineering can then be done on the Java components, and when needed, they can write themselves as Drupal friendly PHP (only enough to interact with selected Drupal modules).
