[keyword] Interface

[uml] IDemoOfForms

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

[uml] IDemoOfPageArguments

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

[uml] IControlledProject

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

You do not always have to use a IControlledProject, but it is a good place to start, with a primary controlled page menu item, a page controller, a set of menu items, and an (optional) layout block.

[uml] IProject

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

You do not always have to use a Project, but it is a good place to start, with a primary menu item, a set of menu items, and an (optional) layout block.

Except for the CurrentPosts example here - which extends AbstractProject and uses a non-OO page callback function in the .module file - you should ALWAYS when working with OOE extend AbstractControlledProject so that you have an OO page controller and a page menu item !

[uml] IBlockView

Webel module:

UML element type:

OOE stereotypes:

[uml] IBlockSet

Webel module:

UML element type:

OOE stereotypes:

[uml] IBlock

Webel module:

UML element type:

OOE stereotypes:

One would not usually show so many related wrapper Components in an analysis interface diagram, however the Enum-like encapsulators of permitted values for $cache, $visibility, and $status are relevant here. For the moment they are represented as static constant attributes of wrapper Components, however one could also model them as literals of UML Enumerations.

There are many strategies for imitating Enums in PHP , but until a decision is made about which way to go, it at least helps to have some encapsulation of allowed values as shown. See also the code example below:

[uml] IMenuItemSet

Webel module:

UML element type:

OOE stereotypes:

This diagram includes some additional explanations regarding the relationships in the Webel «!analysis» @Interface and «!wrapper» @Component modeling system.

One wouldn't normally show and discuss so much concerning Components on an Interface diagram, usually it's just enough to show one concrete or abstract implementor @Component for each @Interface, and the matching design Class for the reverse engineered PHP Interface.

[uml] IModuleMap ["bridge"]

REFACTOR: this software engineering content is flagged as under consideration for refactoring.

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

A module map serves only to encapsulate the contents of every method of the the main .module file of a single module.

Every single function of an OOE style module should delegate to a matching method here with identical parameter signature.

This enables PHP-to-UML extractors to represent the hook functions and "by convention" handler methods of the .module as class methods.

The ability to represent Drupal in graphical Unified Modeling Language (UML) is a major contribution and priority of the OOE tutorial module.

[uml] IPageController

TODO: this content is incomplete, unfinished, or under construction.

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

[uml] IMenuTabs

Webel module:

UML element type:

OOE stereotypes:

extends [Generalization]: 

[uml] IModuleHelper

TODO: this content is incomplete, unfinished, or under construction.
REFACTOR: this software engineering content is flagged as under consideration for refactoring.

Webel module:

UML element type:

OOE stereotypes:

[uml] IMenuItem

Webel module:

UML element type:

OOE stereotypes:

Pages

Subscribe to RSS - Interface