With sincere gratitude from Webel IT Australia to Drupal CMS. Although it's not perfect, it is very powerful and is very popular with good reason.
If you look at the earliest code commits you'll see that the 2nd order $entity2flag map array was originally used directly; the module was refactored so that this helper class encapsulates it and only exposes value-added access methods.
$entity2flag
This "logical" analysis wrapper Component is for graphical organisation only. It does not (in this case) change the logical grouped elements' ownerships, but it does indicate a possible future packaging.
The "unwrapped" diagram for the logical grouping component, showing Component Realization relationships to the logically (and otherwise graphically/visually) grouped participants.
The @Component is still (in this case) in fact contained (owned by) the Package 'flagplus', because how it was moved (dragged) as a graphical symbol into another graphical Component symbol, in MagicDraw UML ! By contrast, in MagicDraw UML, if you drag a Packageable model element in the project browser instead of in a diagraminto a Component it will change ownership ! Both of these modes yield fully compliant UML diagrams.
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.
theme_flagplus_page_bybundle_with_subforms()
flagplus_form_bybundle_ajax()
theme()
build
BybundleFormBuilder
BybundleAjaxBuilder
EntityFilter
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.
module_load_include
flagplus.entitytype.inc
flagplus.flags.inc
We can however instead represent the 3 different "scenarios" handled by this one include file in separate diagrams (as shown below).
CASE: build a readonly page showing the applicability of each Flag by entity type and bundle name in a table.
Those Dependencies between Operations are starting to look a lot more useful when a scenario is isolated !
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.
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.
Currently the .module is triggering the actual building of the Banners Decorator or Banners Block feature via BannerHelper. The flagplus.banners.inc is only responsible for administration of the global banner settings (as system variables) and the per-Flag banner settings (from a DB table),
.module
BannerHelper
flagplus.banners.inc
A switch now enables one to explore delegation to different submit handler versions.
Typically an OOE controlled project has a controller for a main page and a matching page menu item.
A specific project may add additional menu items (possibly for page controllers) for separate pages. In this demonstration, in addition to the main controlled welcome page for the argument extraction demos, there are 4 different sub menu items for 4 demonstration cases:
1. Demo of automatic page path argument extraction, via a Drupal hook in the .module file. Uses a basic IMenuItem.
2. Demo of page path argument extraction with some forced arguments, via a Drupal hook in the .module file. Uses a basic IMenuItem.
3. Demo of page path argument extraction for an OOE controlled page. Uses an IPageMenuItem and a page controller.
4. Demo of page path argument extraction with C. Skene's original PageController. Uses a basic IMenuItem.
The best UML tools like MagicDraw UML are able to show inherited properties in composite structure diagrams. Here they are grouped for illustration purposes.
In the best UML tools like MagicDraw UML one can show the structure compartment of Classes and Components and their composite structure as Property symbols in "hybrid" class or implementation diagrams. Here the inheritance of all major properties is shown.
The attribute and operation compartments of many related elements have been opened here for purposes of illustration, usually in such diagrams dedicated to a given wrapper Component one instead focuses just on that Component, but here we can see more of the collaboration between elements.
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.
Please note, normally one would not show so many Associations to Classes/Components external to the focus Package in such a Package overview diagram; that is usually the job of the focus implementation Component diagram for each Component (such as for @OoeModule).
PLEASE NOTE: You do not have to usually diagram like this with the associated elements inside the wrapper @Component I am just showing you that it is possible in MagicDraw UML. It has some pros (such as it groups the elements nicely a bit like an enclosed machine) and some cons (it can be a bit unstable as far as the diagramming of the lines goes). Compare with a composite structure diagram, or a hybrid diagram with an exposed structure compartment.
Please note also, this is a special case giving an overview of an "anti-example"; normally one would not show such detail in a package overview diagram.
This diagram, because it is for an important demo, features more relationships around @DemoOfPageArguments that one would normally show in a package overview diagram; usually these would only be shown in the focus component diagram for @DemoOfPageArguments.
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.
'It ain't necessarily so, It ain't necessarily so, The t'ings dat yo' li'ble, To read in de [Drupal6/7] Bible, It ain't necessarily so.'
Heresy: Doctrine rejected as false by religious authorities.
Logical fallacy: Appeal to popularity, Argumentum ad populum.