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.
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.
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.
Because PEAR:PHP_UML can only reverse engineer PHP Class and Interface files (not "flat" Drupal7-style .module or
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.
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: 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.
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.
© Copyright 2001 - 2016 Webel IT Australia (ABN: 67 677 268 579). All rights reserved (except as specified below).
PHP code examples from Webel IT Australia on this site are distributed under the GNU General Public License.
Excludes text and code snippets from Drupal.org quoted for educational purposes.
Drupal’s online documentation is © 2000-2014 by the individual contributors and can be used in accordance with the Creative Commons License, Attribution-ShareAlike 2.0.
PHP code from Drupal.org is distributed under the GNU General Public License.
Drupal® is a registered trademark of Dries Buytaert.
Text quoted from Wikipedia for educational purposes is made available under the Creative Commons Attribution-ShareAlike License.
Wikipedia® is a registered trademark of the Wikimedia Foundation, Inc., a non-profit organization.
Site developed by Webel IT Australia.