Revision of Zupal III from 27 January, 2010 - 13:06

I think one of the problems with Zupal is that I started at the domain end instead of looking into the hook system which is at the heart of Drupal.

The hook system is essentially the observer pattern externalized. But to some extent it is lopsy because the event system was applied incompletely. That is: the mechanisms that Drupal itself runs on are not hooks but are task solving PHP blocks.

That is one of the reasons that people still have to write modules in PHP.

So, what if we incorporated an event structure into the internal workings of Drupal/Zupal and made it wholly event driven? that is, everything from saving a record to creating a form revolved around the same hook / observer system?

What this means is that your entire systems architecture could be built up, semantically, around a single architectural element. That is, EVERYTHING -- forms, templates, config settings -- extends from a basic Data class which can be stored in the database and/or JSON, journaled, and created and maintained using a singular administrative interface.

The hook system then becomes a messaging system between data. The URL goes through the routing system, triggers a resolution data item to be loaded, and it cascades calls throughout the data network to resolve the call into a visible (HTML generally) artifact.

Starting from this architecture you could really build not only any website but practically any other software artifact you feel like. You would get the benefits of the Drupal architecture -- open and semantic data mapping, decoratable views and forms, etc., which would extend from the basic elements as needed. The implementing code would exist in class files generated to handle the operations of the interfaces using classic OOP and the whole system becomes extremely "Design by contract".

The DataSource interface, being responsible for tactical I/O, could be wrapped around any ORM. The View system could adapt to an existing templating engine, or core PHP. The form engine would probably have to be custom and intrinsic to the Zupal engine, as would theming and display blocks.

Using this semantically driven architecture you can accomlish just about anything -- and definately the architectural wins of Drupal.