[uml] OoeBridge

Submitted by webel on Tue, 2014-01-14 20:22
REFACTOR: this software engineering content is flagged as under consideration for refactoring.

Webel module:

Package/Namespace: 
Drupal\ooe\Demo\Module

UML element type:

OOE stereotypes:

Relationships
extends [Generalization]: 
AbstractModuleMap ["bridge"]
API page: 
OoeBridge/7.x-1.x

The OoeBridge is the "go-between" that translates from the hooks of the Drupal core world in the ooe.module file and the truly object-oriented, UML-friendly, Webel style OOE PHP code.

Please do not be discouraged by the complexity of this large OOE module bridge overview diagram !

Most other UML diagrams in this OOE tutorial are broken down into smaller, easier-to-digest portions according to a tried and tested modelling recipe. By contrast, this diagram below deliberately provides an overview of the entire demonstration system.

TIP: Click on it to open it in a lightbox viewer then choose the download original link to open it in a web browser tab, where you can easily zoom in and out.

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:

I have tried above to show some of the landscape of OOE beyond the OOE Project classes to which the bridge delegates most of the work, such as menu items, page controllers, and blocks. Each OOE Interface and Class is otherwise presented in easy-to-understand UML diagrams that mostly only show each element's nearest neighbour relationships.

Refactoring

Consider using an IModule interface with a $name and $displayName instead of passing a $module string around. This would require however a major migration of the existing tutorial module code and diagrams.

Consider using an object-oriented access and access arguments handler.

When using OOE page controllers and form controllers with methods as validate/submit handlers, one does not have to pollute the .module file with so many custom callback functions. All you usually need are the main Drupal module hooks like hook_menu(), hook_block_info(), hook_block_view() etc., and these are handled in the bridge very efficiently with menu sets and block sets that collect the required information from, for example, OOE Project classes, and then pass it all back to Drupal as old-style Drupal structured arrays, or however Drupal core requires it.

There are however still some callback functions and form submit and validate handlers in the ooe.module file - with matching delegates in the OoeBridge - just to show you the old way of doing it (without OO controllers). This includes the CurrentPosts demo, which does not have a page controller and calls back directly on a ooe.module file function, and those parts of the DemoOfPageArguments and DemoOfForms that do not use page or form controllers - also included just to show you the old way of doing it.

In other words, usually when working with OOE your .module file and your OO bridge class (extension of AbstractModuleMap ["bridge"]) will be significantly smaller than the one shown here.

Most of the hard work of the bridge is done through delegation to lazily instantiated OOE Project classes, usually extensions of AbstractControlledProject, such as Demo, DemoOfForms, DemoOfPageArguments .

Notes (policies)
Demos
OOE: Demos welcome page
Visit also

Backlinks: