A tutorial site with custom module examples and an object-oriented bridge for Drupal7 core. With graphical UML models !
Thanks Drupal CMS !
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.
Quickstart
- UML for PHP-driven Drupal7
- Software Design Patterns and Anti-Patterns
- About the Webel IT Australia demo for Drupal7
- Getting started
- Q: How is this site different from other Drupal7 demos ? [slideshow]
- It employs an extensive educational object-oriented tutorial module called OOE
- The author Dr Darren is a fan of model-driven software-engineering with graphical Unified Modeling Language (UML)
- The OOE module promotes Don't Repeat Yourself (DRY) coding instead of Write Everything Twice (WET) coding
- This site demonstrates via the OOE module an object-oriented bridge to Drupal7 core
- This site progressively includes UML analysis diagrams of the OOE tutorial module !
- This site uses a "self-referential" educational strategy to expose Drupal concepts to developers
- When coding against OOE Classes one never has to touch a Drupal structured array or structured array key directly
- OOE = Object Oriented Examples = One Of Each
- Download: a Drupal-7.x-dev patch to support the OO form controllers of the OOE tutorial module
- Download: OOE bundle with adapted Drupal-7.36 and installation instructions
- OOE graphical UML models
- Analysis vs Design(ed): The Webel recipe for associative graphical UML modelling of reverse engineered PHP using «!analysis» @Interfaces and «!wrapper» @Components
- Drupal\ooe
- Drupal\ooe\Admin
- Drupal\ooe\Block
- Drupal\ooe\Demo
- Drupal\ooe\Factory
- Drupal\ooe\Form
- AbstractFormController
- AbstractFormField
- AbstractFormGroup
- Form
- FormControllerMenuItem
- FormFieldset
- FormItem
- FormMenuItem
- FormSubmit
- FormTextField
- FormValueField
- IForm
- IFormController
- IFormControllerMenuItem
- IFormField
- IFormFieldset
- IFormGroup
- IFormItem
- IFormManager
- IFormMenuItem
- IFormSubmit
- IFormTextField
- IFormValueField
- Drupal\ooe\Layout
- Drupal\ooe\Menu
- Drupal\ooe\Module
- Drupal\ooe\Page
- Drupal\ooe\Project
- Drupal\ooe\Render
- Drupal\ooe\Theme
- Drupal\ooe\Utility
- Drupal\ooe\Xhtml
- Drupal\page_controller\Controller
- Webel: ooe «!stereotypes» profile
- Demonstrations of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP
- News: Downloads now available: Drupal7 core patch required to support object-oriented form controllers; and OOE bundle with patched Drupal-7.-36
- OOE: Drupal.org project application checklist [mirror]
- OOE: Drupal.org project page [mirror]
- OOE: Notes: programming, policies, conventions, tips
- OOE: a get() method always returns a Drupal array or string; it means you are leaving the purely object-oriented OOE world and entering the Drupal world of structured PHP arrays enforced only by convention and documentation.
- OOE: If you want to use a project you should ALWAYS extend AbstractControlledProject (not AbstractProject) so that you have an OO page controller !
- OOE: The only class that is ever allowed to extend AbstractProject and implement IProject directly is the CurrentPosts demo, which uses an "old" non-OO style page callback to a function in the .module file ! It is a counter-demo !
- OOE: special tweaks to Drupal7 core's form.inc required to support object-oriented form controllers
- Screenshot: NetBeans IDE prompting on an OOE IMenuItem encapsulating a Drupal7 menu item
- Video: Demonstration of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP {MediaElement}
- Video: Demonstration of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP {MediaFront}
- Webel UML for PHP: necessary departures from Drupal coding and documentation standards: special OO bridge method naming conventions; and UML-friendly 'I' prefix Interface names
- Some problems with Drupal that the truly object-oriented approach of the OOE module solves
- Flag Plus
- Flag Plus: graphical Unified Modeling Language (UML) models for PHP
- flagplus.module
- includes
- Drupal\flagplus
- flagplus.info
- flagplus.install
- @Drupal7
- Q: What is the gist of the Webel modelling recipe for UML as applied to PHP ?
- Q: What is the point of the exercise and if you are such a keen UML/OOP nut why are there still so many static helper classes in this Flag Plus UML demo instead of classes that implement interfaces (design by contract) ?
- Q: What UML modelling tool and what methodology are you using ?
- Flag Plus: graphical Unified Modeling Language (UML) models for PHP
- M00: a template for contributed modules
Media
Zones
- OOE = Object Oriented Examples = One Of Each
- Download: a Drupal-7.x-dev patch to support the OO form controllers of the OOE tutorial module
- Download: OOE bundle with adapted Drupal-7.36 and installation instructions
- OOE graphical UML models
- Analysis vs Design(ed): The Webel recipe for associative graphical UML modelling of reverse engineered PHP using «!analysis» @Interfaces and «!wrapper» @Components
- Drupal\ooe
- Drupal\ooe\Admin
- Drupal\ooe\Block
- Drupal\ooe\Demo
- Drupal\ooe\Factory
- Drupal\ooe\Form
- AbstractFormController
- AbstractFormField
- AbstractFormGroup
- Form
- FormControllerMenuItem
- FormFieldset
- FormItem
- FormMenuItem
- FormSubmit
- FormTextField
- FormValueField
- IForm
- IFormController
- IFormControllerMenuItem
- IFormField
- IFormFieldset
- IFormGroup
- IFormItem
- IFormManager
- IFormMenuItem
- IFormSubmit
- IFormTextField
- IFormValueField
- Drupal\ooe\Layout
- Drupal\ooe\Menu
- Drupal\ooe\Module
- Drupal\ooe\Page
- Drupal\ooe\Project
- Drupal\ooe\Render
- Drupal\ooe\Theme
- Drupal\ooe\Utility
- Drupal\ooe\Xhtml
- Drupal\page_controller\Controller
- Webel: ooe «!stereotypes» profile
- Demonstrations of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP
- News: Downloads now available: Drupal7 core patch required to support object-oriented form controllers; and OOE bundle with patched Drupal-7.-36
- OOE: Drupal.org project application checklist [mirror]
- OOE: Drupal.org project page [mirror]
- OOE: Notes: programming, policies, conventions, tips
- OOE: a get() method always returns a Drupal array or string; it means you are leaving the purely object-oriented OOE world and entering the Drupal world of structured PHP arrays enforced only by convention and documentation.
- OOE: If you want to use a project you should ALWAYS extend AbstractControlledProject (not AbstractProject) so that you have an OO page controller !
- OOE: The only class that is ever allowed to extend AbstractProject and implement IProject directly is the CurrentPosts demo, which uses an "old" non-OO style page callback to a function in the .module file ! It is a counter-demo !
- OOE: special tweaks to Drupal7 core's form.inc required to support object-oriented form controllers
- Screenshot: NetBeans IDE prompting on an OOE IMenuItem encapsulating a Drupal7 menu item
- Video: Demonstration of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP {MediaElement}
- Video: Demonstration of NetBeans IDE prompting on an OOE IMenuItem encapsulation of a Drupal menu item in object-oriented PHP {MediaFront}
- Webel UML for PHP: necessary departures from Drupal coding and documentation standards: special OO bridge method naming conventions; and UML-friendly 'I' prefix Interface names
- Some problems with Drupal that the truly object-oriented approach of the OOE module solves
- Drupal facts, info, and tips
- Drupal: general TIPS external links
- Drupal and web services
- Definition: Universal Description Discovery and Integration (UDDI)
- Definitions: Business Process Execution Language (BPEL)
- Definitions: RESTful web services: Representational state transfer (REST)
- Definitions: SOAP web services
- Definitions: UUID and GUID
- Definitions: Web Application Description Language (WADL)
- Definitions: Web services
- Definitions: Web Services Description Language (WSDL)
- Links: Web services: TIPS, info, tutorials, libraries for Drupal and PHP
- RESTful (WADL) and/or SOAP (WSDL)
- Drupal Commerce and Rules
- Drupal7 SECURITY
- Drupal: how debug a White Screen of Death (WSOD)
- Drupal: tracking traffic, load testing, performance
- Mac OS X as a Drupal development platform: installation, setup, configuration
- Drupal module development
- Drupal7 AJAX commands (outside forms)
- Drupal7 API documentation and comment standards
- Drupal7 coding standards
- Drupal7 entities, bundles, and fields
- Drupal7 Forms, the Form API (FAPI), and Forms tutorials
- Drupal7 translation, localization, and the t() function
- Drupal7: essential global functions and hooks
- Drupal7: on splitting module code into separate .inc include files
- Drupal7: render arrays
- Drupal7: the Database API and Schema API
- Main Drupal7 API reference examples
- PHP namespaces in Drupal (and autoloading)
- TIP: communicating with external URLs and external sites
- TIP: dealing with dates, times, and timezones in Drupal7 (and PHP)
- TIP: dealing with Drupal (menu) paths, path arguments, and path wildcards
- TIP: Debugging Drupal (and PHP applications)
- TIP: Drupal7 menu tricks
- TIPS: Drupal and Git repository management and versioning
- TIPS: Drush command line tools for Drupal
- TIPS: patches in Drupal7
- Drupal7 theming
- The Webel «!wrapper» @Components and «!analysis» @Interfaces recipe
- Webel UML recipe for PHP: Notes: modelling policies, conventions, tips
- A guiding principle is that a form-related include bridge file should use one and one only helper/builder class with delegation from each of the form _build(), _ajax(), _validate() and _submit() functions of the bridge include file.
- A utility or helper Class that will never be swapped or substituted for in its client Class need not implement an Interface; its public methods serve as the interface.
- A «!new» stereotype assigned to a Usage from a source Classifier (or a creation method) means an instance of the target Classifier is created directly (instead of fetching an Interface product via a factory) and assigned to a «!chosen» Interface var.
- An analysis @Component may replace weakly specific PHP 'object' parameter types with stronger placeholder analysis @Interfaces in its operation signatures.
- An «!analysis» @Interface in a class diagram may show a UML Usage (requires) to another referenced «!analysis» @Interface type. This can be displayed as a UML "Usage socket" symbol.
- Convention: Once you are used to the idea that each design(ed) UML Class element is being reversed from a source Artifact you may leave it off such diagrams. (It can always be traced to a source anyway using the «manifest» relationship.)
- Create "bridge" include files that mediate between the classic Drupal7 hooks of the .module file and OO Class libraries that progressively encapsulate define() data and functions as Class attributes, constants, and Interface/Class methods
- DIRTY TRICK for reverse-engineering "flat" Drupal7-style .module and .inc PHP files into methods of Webel-style wrapper @Components
- DRY: Golden Rule: never use the module machine name (or the human-friendly module display name) in a naked string in code, always obtain them via the Common::module constant.
- Even in dedicated "focus" class diagrams showing too many Dependency arrow symbols between operations and/or attributes can lead to clutter; sometimes it is useful to create Dependency relationships in the UML model but not show them in all diagrams
- Focus diagrams do not always show every relationship between all elements; usually only the main relationships from the focus element to neighbours are shown. Relationships between its operators and neighbours and between neighbours are not always shown
- GOLDEN RULE: a parameter of an operation/method of an «!analysis» @Interface or «!analysis»/«!wrapper» @Component MUST NEVER reference a design layer element as its Type (except for low-level PHP primitive types and stdClass)
- Graphical UML moral: if the focus/overview diagram of a Class or Package/Model is overly complex DO NOT be discouraged, it is a hint that your system needs refactoring ! Begin by creating "scenario" sub-diagrams that each identify a narrative.
- If a code element is not yet reversed from PHP into a design layer UML element it may be represented in the analysis layer by a pure «!analysis» @Interface or a pure «!analysis» @Component (but NOT yet a «!wrapper» @Component).
- IMPORTANT: PEAR:PHP_UML reverses the PHP 'implements' as a UML Realization from a "design(ed)" Class to an Interface; in the Webel recipe this is represented in the analysis domain as an InterfaceRealization from a wrapper @Component to an @Interface !
- In MagicDraw UML and the best UML tools one can choose to exclude certain information about selected attributes (such as default values) and operations (such as operation signature) in their respective compartments to leave a minimal hint of their roles.
- In MagicDraw UML and the best UML tools one can choose to show only selected attributes and selected operations in their respective compartments.
- In MagicDraw UML, depending on how you manipulate the elements, Components do not automatically "steal ownership" of the elements they graphically contain. In the Webel recipe «!logical» Components are used for convenient "parasitic" graphical groupings.
- In Package/Model overview diagrams it can sometimes be useful to show the operations compartment, as long as it does not lead to clutter; in MagicDraw UML one can choose to show operations without the full operation signature.
- 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.
- In the UML-friendly Webel PHP Interface names are always prefixed with capital 'I' thus ICamelCase ! This has many advantages for graphical UML modelling and IDE based prompting (and saves typing) This is knowingly NOT the Drupal coding standard !
- In this diagram the UML containment operator is used between Package/Model symbols and their contained elements, rather than graphical containment.
- It is not always necessary to show the Package/Model symbol in a "focus" class diagram or implementation diagram; one can rely on the indication of ownership of each element (usually displayed under the element's name on its symbol).
- It is strongly recommended that implementation Classes use full private property vars with protected lazy creation/configuration methods (rather than just local variables) ! It has many advantages and is UML friendly ! (TIP: use code template expansion.)
- MagicDraw UML has a powerful model validation engine that indicates invalid configurations in diagrams (such as indications of invalid Package/Model ownership of child elements).
- MagicDraw UML: does not permit drawing a Dependency (or Usage) from a Property name symbol or line end of an Association, makes it hard to indicate a chosen implementation Class. Workaround: draw from Property symbol in composite structure compartment.
- MagicDraw UML: it is often handy to open the (usually empty) attributes compartment of an Interface symbol so that it displays as a rectangle and can be more easily targeted by relationships than the Interface icon. This DOESN'T mean it has no operations!
- PEAR:PHP_UML:ERROR: can't properly reverse engineer default values of attributes defined via static constants of other classes.
- PHP 'use' statements in a PHP include file or class/interface file are modelled using the UML Usage «use» relationship (from a «!wrapper» @Component corresponding to the file that has the 'use' statement to a «!wrapper» @Component for a Class/Interface).
- Q: Why aren't you making (more) use of database functionality of the core Drupal7 entities, "fieldable" entities, and the Entity API in your graphical UML for PHP demos ? A: Because I have not yet reversed those aspects of Drupal7 into graphical UML.
- Q: Why do some diagrams and models contain so many static public methods and basically fully static "Helper" and "Builder" Classes with only a few instantiated objects ? A: It's an interim step for progressive migration to classes and objects.
- The stereotype «!by» is just shorthand for «!encapsulated by»
- The Webel «!wrapper» @Component strategy enables associative representation of array properties that are not caught by PEAR's PHP UML when applied to Drupal-style array documentation.
- The «!chosen» stereotype on a Property variable typed by an Interface indicates that a default concrete implementation Class is chosen for it by the managing Class (not via a factory), usually in a lazy creator method of the same name as the Property.
- The «!default» stereotype on a Usage from a composite structure compartment Property symbol to a Class indicates it is assigned as the default (usually in a lazy creator of the same name as the Property) by the managing class.
- The «!page» stereotype on an operation or method indicates that it returns a Drupal render array for a page.
- The «!product» stereotype on a Property variable typed by an Interface indicates that a concrete implementation Class is supplied for it by a factory.
- The «!render» stereotype on an operation or method indicates that it returns a Drupal render array portion for a page (or form).
- TIP: If you run out of room sometimes it's handy to draw hierarchies "upside down"
- TIP: In MagicDraw UML one can include external image resources (such as screenshots) in UML diagrams !
- UML ElementImport «import» relationships are used to model Drupal7 'file' includes for hook_menu() and hook_theme()
- UML Package/Model symbols can be useful for graphically organising the symbols of the elements they own but they are fragile against change of ownership. They are essential for Package/Model overview diagrams but not always advised in class diagrams.
- UML PackageImport «import» relationships are used to model analysis dependencies between Packages/Models. They do not correspond to a PHP artefact, but do imply that a contained element has a matching PHP file with a PHP 'use' to a file in the target.
- UML: just because an operation or attribute is not shown in a compartment of a Class or Component symbol (in a given diagram) does not mean it is not present in the underlying UML model !
- Using Dependency arrows between operations in class diagrams can be useful in dedicated mini-diagrams, but it quickly leads to clutter in large overview diagrams.
- Webel: in MagicDraw UML if you move a suitable element symbol IN A DIAGRAM into a Component symbol IN A DIAGRAM that "outer" Component won't "steal ownership", so it can be used as a «!logical» grouping container.
- Webel: «!issue» analysis Components can be used to help track issues and bugs graphically via Dependency and Component Realization relationships. Use the name of the component to hold a verbose description of the issue !
- Webel: «!logical» Components used for convenient "parasitic" graphical groupings may be shown "unwrapped" in diagrams that reveal the Component Realizations to the logically (and otherwise graphically) grouped participants.
- When drawing hierarchies of Interfaces it is sometimes easier if you open up the empty attributes compartment of the Interface symbol so that it shows as a rectangle, not just as the Interface circle icon/symbol (but not operations in overview diagrams)
- Webel UML recipe for PHP: Notes: modelling policies, conventions, tips
- UML for PHP-driven Drupal7
- PHP for Drupal
- Documenting PHP constants in Drupal
- Enums in PHP
- In PHP(5.3) arrays are not significantly faster than objects (if at all)
- PHP magic functions and "overloading"
- PHP: Integers
- PHP: validation filters
- TIP: PHP file inclusion workarounds for many Drupal hook functions in one module
- TIP: workarounds for inability to overload methods (esp. constructors) in PHP
- PHP does not support type casting directly
- Software Design Patterns and Anti-Patterns
- Dr Darren's "Manifesto": Drupal coding needs to (really) change !
- Drupal heresy
- Dr Darren says: 'Having to remember structured array key conventions in Drupal7 instead of being able to prompt on intelligent, documented, methods of objects in any modern IDE is a complete pain !"
- Dr Darren says: 'Just because I (constructively) criticise some aspects of Drupal core and the module development API does not mean I don't appreciate Drupal and what one can do with it'
- Webel's postings to Dries about UML for PHP-driven Drupal
- Some other people who also seem to think that Drupal6, Drupal7 (and still Drupal8) is not coded very well and is not OO enough
- Drupal(7) venting, rants, and ROTFL from others
- TIP: NetBeans support for Drupal
- Towards OO in Drupal8 (almost)
OOE: Current posts
OOE: Demo block
My translatable content.
Drupal7 coding standards
Submitted by webel on Sun, 2014-01-26 18:41
Apart from the external links below, there is far more detailed discussion of the Drupal Coding Standards here on this site - with an emphasis on compatibility with Webel's UML-friendlier PHP coding style - under the Coder module review page and under Drupal7 object-oriented coding standards.
For NetBeans IDE users, you can greatly reduce the pain of endeavouring to meet the Drupal Coding Standards with these useful tips:
- External: Configuring NetBeans (to format your code according to Drupal Coding Standards).
Please get rid of the verbose Drupal "Interface" suffix naming convention !
I consider the following Drupal OO recommendation completely unnecessary and not UML-friendly:
7. Interfaces should always have the suffix "Interface".
In the The Webel «!wrapper» @Components and «!analysis» @Interfaces recipe, interfaces are instead prefixed with a capital I followed by a CamelCase name like ICamelCase. This has many advantages:
- The 'I' acts like the Interface icon in UML and makes for much easier and more compact diagramming.
- It saves a massive amount of typing !
- It makes it much easier to prompt in IDEs and UML tools like MagicDraw UML on Interface elements, by just prompting on the 'I'. How on earth is one supposed to prompt on a suffix "Interface" ?
I will fight "tooth-and-nail" to get rid of the DrupalInterface suffix convention !
It has clearly been conceived by people who are likely not frequent graphical UML users, and are perhaps even relatively new to object-orientation. In modern IDE's like NetBeans or Eclipse and when using graphical UML support it is already perfectly clear whether something is an interface or not, one does not need to spell it out painfully with the word Interface. The UML-friendly OOE = Object Oriented Examples = One Of Each module will never, under any circumstances, adopt the verbose "Interface" suffix convention.
If you are likewise opposed to this convention, please join the debate at: Drupal.org: Object-oriented code (naming conventions): Please relax the verbose Drupal "Interface" suffix convention !
Backlinks:
-
[Module ] Coder
Webel for Drupal !
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.
Please donate to the OOE project !
Navigation
Contributed module demos
m00: Stub block
Stub m00 block content
Drupal heresy
'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.
User login
© 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.