Table of Contents
Modules are the most advanced customization method available in dmBridge. They enable the addition of complex new functionality as self-contained units of code.
To write a module, you will need a firm grounding in object-oriented PHP programming, including classes, interfaces, exception handling, class inheritance, accessors, instance methods, and static (class) methods. dmBridge is architected in a way that could be considered more-or-less "standard Java OO" - at least to the extent that that can be achieved in PHP 5.2 - and although your modules do not have to work like this, they will need to interface with the dmBridge PHP API, which does.
With a module, all of the following are possible without modifying any built-in dmBridge code:
Add new HTTP API URI routes
Add new template engine URI routes
Add new URI routes of any other kind
Add or override controllers that responds to any of these routes
Output your own HTTP content representations in any route
Write your own template helpers (if your module uses HTML templates)
Add sections to the Control Panel containing your own custom forms
Set up and query your own custom tables in the dmBridge data store
The process of writing a dmBridge module is fairly complex compared to authoring a template helper or custom viewer. However, the ability exists for developers who require it. As in any other reasonably complex object-oriented API, persistence pays off.
Modules should be built to work in PHP 5.2.
Modules should use distinctive class, function, constant, and variable names as necessary in order to avoid naming clashes.
Modules should not require any PHP extensions beyond those required by dmBridge (this is suggested but not required).
The module's folder should contain all the code necessary to make the module work.