Module Development Guide
Modules should be designed for security and extensibility, provide a clear separation of logic and presentation, and output meaningfully structured XHTML.
Code Standards
- Modules should be object-oriented vs functional, with extensibility in mind
- Cleanup rules should explicitly define acceptable user input, and sanitize all user-input appropriately
- The use of superglobals ($_SESSION, $_GET, $_POST, etc) should be avoided as much as possible - use sanitized variables in $this->request
- The information a module needs to function should be defined in
- the reason db (entities)
- parameters passed by page_type.php
- class variables
- constants declared in settings.php
- Modules parameters should be optional
- Modules should include or inherit an init(), has_content(), and run() method
- init() - logic layer
- has_content() - determined from logic in init()
- run() - presentation layer
- Existant utility functions (prettify_string, is_mixed_case, check_against_regexp, get_current_url, datetime_to_unix, show_image, etc) should be used whenever possible
Style
- Use semantic XHTML to provide structure to the content presented by reason modules
- Adhere to accessibility guidelines
- Avoid the use of HTML tags for presentation (ie: no tables for layout, blockquote should not used to indent content)
- Avoid using "wrapper" tags such as div and span when a semantic tag can provide appropriate structure
- Modules should use hierarchical headers between h3 and h6 as appropriate - h1 and h2 are reserved for template content outside the module
- The entire output of a module should be wrapped in a div
- The div should be given an id if the module will only be run once per reason page
- The div should be given a class if it could be repeated on a page
- The id or class should be titled with the same name as the module class name, with the first character made lowercase and the word Module removed. For examples (BlogModule = blog and BioBookModule = bioBook)