OOE: Demo block

My translatable content.

[note]
Create "bridge" include files that mediate between the classic Drupal7 hooks of the .module file and OO Class libraries that progressively encapsulate define() data and functions as Class attributes, constants, and Interface/Class methods

UML diagram type:

UML modelling domain:

The themed builder theme_flagplus_page_bybundle_with_subforms() for the non-AJAX "by bundle" flag applicability form and the non-themed builder flagplus_form_bybundle_ajax() for the AJAX version of the flag applicability form delegate to theme() and build of BybundleFormBuilder and BybundleAjaxBuilder respectively, which in turn use the EntityFilter helper class, which defines callbacks.

But from the point of view of Drupal7 (which as of Drupal-7.36 still does not fully support object-oriented methods as callbacks), it has to callback on something known at the include file level where the form builder is originally invoked. So a module_load_include of flagplus.entitytype.inc (which handles delegating callbacks for EntityFilter) is performed in flagplus.flags.inc.

UML diagram type:

UML modelling domain:

CASE: build an editable form enabling the applicability of each Flag by entity type and bundle name to be seen and set in a table, with an entity type filter.

A bit more complex because now it includes and entity type filter sub-form and sub-forms for applicability of each Flag by entity type and bundle. But the Dependencies between operations do definitely help trace the logic.

,

UML Diagram

Click on the UML diagram to view it in a lightbox image viewer. You may then zoom in (or just open the image in a new web browser tab using the Download Original link to view large diagrams).

UML diagram type:

UML modelling domain:

CASE: build an editable AJAX form enabling the applicability of each Flag by entity type and bundle name to be seen and set in a table, with an AJAX entity type filter.

Also not bad except for those horrible long operations in the include file flagplus.flags.inc, which is a a typical consequence of lack of OOP, and of Drupal7's system for passing arguments to non-OOP callbacks functions (unless you like shoving it all into an unstructured "$options" array as so often done in Drupal, which is also rather blech and yuck).

Notice how, compared with the non-AJAX form case, the entity filter sub-form is handled a bit differently; instead of it being built with a default from a system variable it is built using the form state value from the AJAX callback.

Webel for Drupal !

This educational site is brought to you by Webel IT Australia, experts in database-driven web technology for industry, engineering, education and science. Webel is one of Australia's most experienced Drupal CMS web site specialists.

Please donate to the OOE project !

The OOE module is the start of something very big, a completely object-oriented, IDE-friendly module development system for Drupal7, which encapsulates forever the complexity of "by convention" structured Drupal arrays in Classes. If you are a fan of object-orientation, and if you believe there is a better way for Drupal, then please help sponsor this groundbreaking project through a donation.