UML diagrams gallery: full list view

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.

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.

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.

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),

A switch now enables one to explore delegation to different submit handler versions.

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.