[keyword] !policy

Note however that an element that has not yet been reversed from PHP into a UML "design(ed)" model element must NOT yet be represented by a «!wrapper» @Component, because there is no "design(ed)" element to wrap.

By a get() method is not meant a property getter, it means literally 'get()' with no arguments and only 3 letters in the method name ! The get() methods are how OOE talks to Drupal core, they assemble everything to return a valid Drupal array (or string).

The UML signature is always one of:

«!drupal» get() : array
«!drupal» get() : string
«!drupal» get() : string|array

The only exception is the CurrentPosts example, which deliberately extends only AbstractProject and uses an explicit page callback function in the .module file to show you the "old" non-OO way of doing it.

A Webel module bridge for Drupal consists of a special Drupal .module file (say 'ooe.module') and a Webel Drupal-PHP-bridge implementation Class such as OoeBridge for the main OOE = Object Oriented Examples = One Of Each tutorial module.

This enables one to (code modules for Drupal7 in a truly, purely object-oriented PHP and (best of all) one can then also model the module system in graphical Unified Modeling Language (UML) !

This is necessary because the XMI generated by PEAR PHP UML does not integrate with the MagicDraw UML code engineering sets system, one can however import the XMI (into the design packages).

This simple policy is extremely important and effective for graphical Unified Modeling Language (UML) models of reverse engineered PHP using PEAR PHP UML. Advantages include:

- Clear separation of the analysis packages/models from reverse-engineered PHP design class representations (imported by MagicDraw UML from the reverse-engineered PHP UML XMI file).

- Clear indication that an Element is an analysis element (even when no stereotype applies).

This is because in my current combination of MagicDraw UML with PEAR PHP UML the only way I have found to consistently include coding changes to the PHP classes in the MD UML model is to Import From > Another Project .. where the other project is the reverse engineered XMI2 file generated by PHP UML.

This simple policy is extremely important and effective for graphical Unified Modeling Language (UML) models of reverse engineered PHP using PEAR PHP UML. Advantages include: -

- Easy prompting for analysis elements in a UML tool without any risk of hitting reverse-engineered PHP design(ed) elements (Classes/Interfaces/Artifacts).

- Makes it clear in all diagrams which elements are analysis and which are reverse-engineered design(ed) elements, no matter whether the owner/context or stereotypes are shown.