Difference between revisions of "Plugin APIG2"
m (→The Plugin Interface Class) |
m (→Event Manager Class) |
||
Line 96: | Line 96: | ||
<pre> | <pre> | ||
− | class | + | class Geeklog_EventManager { |
/** | /** | ||
* Array containing event keys and listener (arrays as) values | * Array containing event keys and listener (arrays as) values |
Revision as of 21:05, 17 December 2004
Contents
- 1 Introduction
- 2 The Plugin Interface Class
- 3 Event Manager Class
- 4 Events
- 5 Plugin Framework
- 6 Directory Structure
- 7 Function Naming Conventions
- 8 Templates
- 9 Logging
- 10 Apendix A: Helper Functions
- 11 Apendix B: GL2 Core Events
- 12 Apendix C: Potential Plugins
- 13 Apendix D: Example
- 14 Apendix E: Document History
Introduction
Geeklog 2 (GL2) is the next generation of content management systems in the popular Geeklog family. Geeklog is becoming a very popular backend for many sites. However, as development continues in the 1.3.x branch of Geeklog and features continue to be added, several architechural problems have been uncovered. These issues include scalability, performance and weakness is the plugin API.
The goal of the GL2 project is to improve all of these areas. This document draws out the plans for the GL2 plugin API. Until the first official release of GL2, this document can be considered a work in progress. For history details please seen the history section at the end of this document (for releases) or refer to the wiki change log (for a detailed list of changes).
It is especially important to note that it is planned for GL2 to use PHP 5 and make extensive use of the PEAR extenstions to php. These choices, along with a authentication and access engine developed by Tony Bibbs, will shape the implementation of the plugin API.
Plugin Overview
The GL2 plugin architecture will be event based. Each plugin will register to listen for events that are generated by the GL2 kernel and other plugins. The GL2 kernel will act as a router for these events. When an event occurs, the GL2 kernel will call all the plugins that have registered for that event.
The Plugin Interface Class
The main component of GL2 plugins will be the plugin interface class. This class will need to be implemented by all GL2 plugins. The interface class is outlined below:
class Geeklog_PluginInterface { /** * Installs and registers the plugin with the GL2 kernel * * Handles the creation of data structures, security setup, and * registers for events. * * @access public * @return boolean true for success, false for failure */ public function install(); /** * Uninstalls and deregisters the plugin with the GL2 kernel * * Handles the removal of data structures, security setup, and * deregisters events. * * @access public * @return boolean true for success, false for failure */ public function uninstall(); /** * Upgrades the plugin * * Handles the update of data structures, security setup, and * alters the registered for events as needed. * * @access public * @return boolean true for success, false for failure */ public function upgrade(); /** * Gets the plugins version information * * Gets the plugin version information such as version number, * minimum GL2 version, version date, plugin name, and possibly * other information such as dependencies. * * @access public * @return version structure */ public function getVersion(); /** * Event handler * * Executes actions based on events passed to the function by the * GL2 kernel. * * @access public * @param string name of event that requires action * @param mixed variable type (and existence) dependent on event * @return mixed return type depends on event */ public function handleEvent( $event, $var = ''); /** * HTML Page Generation * * Called by index.php (which is responsible for determining which * plugin's getPage to call), this function generates a HTML page * based upon user inputed data ($request). * * @access public * @param array Array of applicable GET and POST variables * @return string HTML of requested page */ public function getPage( $request ); }
Event Manager Class
An instance of the class described below will be created globally by the GL2 core. It will be available to all plugins and is responsible for handling plugin event registration and notification.
class Geeklog_EventManager { /** * Array containing event keys and listener (arrays as) values * This takes the form of $listeners[<eventName>] = * array(<pluginName1>, <pluginName2>, etc); */ private $listeners = array(); /** * PluginEventHandler Constructor * * @author Vincent Furia <vfuria@gmail.com> * @access public * */ public function __construct() { // fetch registered listeners from database, populate $listeners } /** * Register a plugin to listen for an event * * @author Vincent Furia <vfuria@gmail.com> * @access public * @param mixed $event event(s) to listen for (string or array) * @param string $plugin plugin to be registered as listener * @return boolean true on success * */ public function registerListener($events, $plugin) { // add the listener to the $listeners variable and the database } /** * Unregister a plugin from listening for an event * * @author Vincent Furia <vfuria@gmail.com> * @access public * @param mixed $event event(s) to unregister (string or array) * @param string $plugin plugin to be unregistered as listener * @return boolean true on success * */ public function unregisterListener($plugin, $events = '') { // remove the listener for the specified events from $listeners // and the database. If events is empty then unregister the plugin // for all events } /** * Get all the listeners for a specific event * * @author Vincent Furia <vfuria@gmail.com> * @access public * @param string $event event to get listeners of * @return array array of listeners to event $event * */ public function getListeners($event) { // remove the listener for the specified events from $listeners // and the database. } /** * Notify listener(s) that an event has occurred * * @author Vincent Furia <vfuria@gmail.com> * @access public * @param mixed $event event requiring notification * @param mixed $vars event specific variables * @param mixed $plugin NOTIFY_ALL, specific plugin, or array of plugins * @return mixed event specific return values (or array of) * */ public function notify($event, $vars, $plugin = NOTIFY_ALL) { // call the handle event function for each plugin listening to the // relevant event (or, if $plugin specified, only that plugin) } /** * Creates a plugin and returns it * * @author Tony Bibbs <tony@geeklog.net> * @access public * @param string $pluginName Name of the plugin to create * @return object An instance of the given plugin name * */ private function &getPlugin($pluginName) { // creates a instance of a plugin so the plugin can be referenced // by other functions in this Class (i.e. notify). } }
Events
Registering for Events
When a plugin's install() function is called it is expected to register for all the events it will need to handle. This is accomplished using the function registerListener() of the glEventManager class. Similarly within the uninstall() function, the function unregisterListener() of the glEventManager class should be used to deregister event watches.
A plugin should never register for its own events as this has the potential to create infinite loops (as such the glEventManager class will prevent such registrations). In any case such a feature should not be needed, as a plugin can execute any required tasks when an event is triggered.
Handling Events
When an event is triggered, either by the GL2 kernel or by a plugin, the handleEvent() function is called on all plugins registered for that event. At that point it is the responsiblitiy of the plugin to do any required processing and to return an appropriate value.
Each plugin will be responsible for preventing infinite loops caused by handling an event in such a way that the handled event is triggered. Infinite loops can avoided in many cases simply by not triggering any events inside the event handler (if possible).
Triggering Events
When a plugin requires input or believes other plugins may benefit from knowing that a given event has occured, the notify() function of the glEventManager class should be called.
Event Naming Scheme
Event names should be prefixed with the plugin name. The actual event name should be descriptive and may contain subnames seperated by a period ('.'). The word 'core' cannot be used as the plugin name as it is resevered for events triggered by the GL2 kernel.
Some example event names:
- "links.delete" -- triggered when a link from the links plugin is deleted
- "core.userlogin" -- triggered by the GL2 kernel when a user logs in
- "core.userprofile.update" -- triggered by the GL2 kernel when a user profile is updated
Plugin Framework
It is recommended that all plugins be implemented using the MVCnPHP (cvs) class developed by Tony Bibbs. Each plugin will have its own controller and its own set of views and commands.
Directory Structure
All of the files for a plugin are to be kept in a single sub directory of the GL2 plugin directory. The plugin's internal directory structure is based on the MVC framework. The file structure within the plugin directory should look approximate this:
- <plugin name> (dir)
- commands (dir)
- <command1>.class.php
- <command2>.class.php
- ...
- views (dir)
- <view1>.class.php
- <view2>.class.php
- ...
- templates (dir)
- default (dir or softlink)
- <layout1> (dir)
- <layout2> (dir)
- ...
- index.php (controller)
- mvcconfig.php
- config.php
- main.class.php (implemented interface class)
- includes (dir)
- sql (dir)
- mysql.sql
- mssql.sql
- ...
- updates (dir)
- mysql_0.1_0.2.sql
- mssql_0.1_0.2.sql
- ...
- commands (dir)
Function Naming Conventions
To prevent clashes within the namespace (two functions or classes with identical names will cause an error in PHP), the names of all classes and all functions not contained within a class should be prefixed with the plugin's name.
Templates
GL2 will use HTML_Template_Flexy as its template library. Plugins authors are recommended to use this template library for efficiency and consistency.
Logging
Logging will be handled using PHP's built in logging functionality. Specifically, use the trigger_error() function to log errors and messages. Error number constants include: FATAL, ERROR, WARNING, INFO, and DEBUG.
Apendix A: Helper Functions
The GL2 kernel will provide a set helper functions to the plugins. These helper functions will provide functionality in areas such as access and authentication (A&A), search, comments, and event handling.
These functions include:
- ...
In addition, GL2 plugins will have access to the following global classes:
- A&A
- glEventManager
- glLogger
- ...many more
Apendix B: GL2 Core Events
The following events will be triggered by the GL2 kernel. They are known as core events because they exist independent of any installed plugins.
Event | Description |
---|---|
core.begin | GL2 begins processing a page request |
core.end | GL2 finishes processing a page request |
core.adduser | A new user gets added (not self registered) |
core.newuser | A new user registers with the site |
core.updateuser | A users info gets modified |
core.deleteuser | A user account is deleted |
core.userprofile.display | Builds the userprofile is display |
core.userprofile.update | The userprofile is udpated |
core.userlogin | A user logs in |
core.userlogout | A user logs out |
core.menuitems.display | Builds the header menu items |
core.usermenu.display | Builds the user menu display |
core.adminmenu.display | Builds the admin menu display |
core.searchtypes | Gets available search types |
core.search | Performs search |
core.admincontrol.display | Builds the administrative display control |
core.listsblocks.display | Builds a list of available blocks |
core.blocks.display | Builds the blocks for display |
core.moderation.list.display | Should we have a moderation plugin? Or should it be part of the core? |
core.moderation.display | " |
core.moderation.approve | " |
core.moderation.delete | " |
core.submissioncount | " |
core.header.display | Insert javascript/CSS in html <header> |
Some items that are currently handled by Geeklog's 1.3.x plugin system will be implmented as a plugin. This includes items such as the "What's New Block", statistics, and the handling of RSS Feeds.
Apendix C: Potential Plugins
Below are two lists indicating an initial ideas for plugins that could be created for GL2. This list is in no way comprehensive. The categories of Application Plugin and Helper plugin are arbitrary and will not effect how the plugins are created or run. Plugins highlighted in red indicate features that are currently implemented in the base Geeklog 1.3.x branch.
Application Plugins
- Articles
- Links
- Calendar
- Polls
- Staticpages
- File Management
- Forum
- Gallery
- Contacts
- E-Commerce
- Quote of the Day
- Blog/Journel
- Webmail
- Stats/System Status
Helper Plugins
- Cron -- execute delayed/timed events
- Moderation? -- administer moderation of plugin items
- Configuration? -- web based method for changing plugin configuration
- RSS/RDF Feeds -- xml content syndication
- What's New -- shows recently updated/added content
Apendix D: Example
An example plugin is in the works (or will be soon).
Apendix E: Document History
- Version 0.3 (08/07/2004): reformated for the wikit and incorporated comments from geeklog.net.
- Version 0.2 (06/30/2004): updated document with comments from geeklog.net, other improvements as needed. Added Apendix with potential plugins.
- Version 0.1 (04/27/2004): initial release of the documentation for comments