mantisbt:dynamic_plugin_requirements
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
mantisbt:dynamic_plugin_requirements [2007/10/28 16:39] – More comments. vboctor | mantisbt:dynamic_plugin_requirements [2008/10/29 04:25] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 26: | Line 26: | ||
There will need to be a simple and unified method for plugins to maintain their database schema, otherwise plugins will get released without proper upgrade paths for users. | There will need to be a simple and unified method for plugins to maintain their database schema, otherwise plugins will get released without proper upgrade paths for users. | ||
+ | |||
==== Event Types ==== | ==== Event Types ==== | ||
Line 42: | Line 43: | ||
* No return value | * No return value | ||
* Includes EVENT_PAGE_TOP and EVENT_PAGE_BOTTOM | * Includes EVENT_PAGE_TOP and EVENT_PAGE_BOTTOM | ||
- | ** Process | + | ** Chain event ** |
* Event allowing a plugin to process an input string and return a modified version to the originator. | * Event allowing a plugin to process an input string and return a modified version to the originator. | ||
* Parameters: | * Parameters: | ||
Line 81: | Line 82: | ||
* Send EVENT_PLUGIN_INIT signal | * Send EVENT_PLUGIN_INIT signal | ||
* Execute normal page contents with events as necessary | * Execute normal page contents with events as necessary | ||
+ | |||
==== Event Execution ==== | ==== Event Execution ==== | ||
Line 89: | Line 91: | ||
* For each registered callback: | * For each registered callback: | ||
* Include '' | * Include '' | ||
- | * Call '' | + | * Call '' |
* Alter parameters for next callback if necessary | * Alter parameters for next callback if necessary | ||
* Output content if necessary | * Output content if necessary | ||
* Return callback values to event originator if necessary | * Return callback values to event originator if necessary | ||
+ | |||
+ | |||
===== Plugin Hierarchy ===== | ===== Plugin Hierarchy ===== | ||
Line 112: | Line 116: | ||
* '' | * '' | ||
* '' | * '' | ||
- | * '' | + | * '' |
* '' | * '' | ||
* '' | * '' | ||
* '' | * '' | ||
* '' | * '' | ||
+ | |||
+ | |||
+ | |||
==== Sample Plugin (Super Cow Powers) ==== | ==== Sample Plugin (Super Cow Powers) ==== | ||
Line 151: | Line 158: | ||
/** | /** | ||
- | | + | |
*/ | */ | ||
- | function | + | function |
- | | + | |
} | } | ||
</ | </ | ||
Line 165: | Line 172: | ||
* Handle the EVENT_PLUGIN_INIT callback. | * Handle the EVENT_PLUGIN_INIT callback. | ||
*/ | */ | ||
- | function | + | function |
header( ' | header( ' | ||
} | } | ||
</ | </ | ||
+ | |||
+ | |||
===== Feedback ===== | ===== Feedback ===== | ||
* (vboctor): EVENT_TEXT_GENERAL - You might need to differentiate where this text is going, e.g. normal text (like string_display()), | * (vboctor): EVENT_TEXT_GENERAL - You might need to differentiate where this text is going, e.g. normal text (like string_display()), | ||
+ | * (jreese) For now, TEXT_GENERAL is for basic string_display(), | ||
* (vboctor): EVENT_TEXT_GENERAL - I am assuming that you will be pipelining the results of one plug-in into another, right? | * (vboctor): EVENT_TEXT_GENERAL - I am assuming that you will be pipelining the results of one plug-in into another, right? | ||
+ | * (jreese) That is the defined behavior of a processing type event, which TEXT_GENERAL is. Other event types have different behaviors. | ||
* (vboctor): EVENT_TEXT_GENERAL - If you look at the current implementation you will notice that the order of applying the display filters affects the final results. | * (vboctor): EVENT_TEXT_GENERAL - If you look at the current implementation you will notice that the order of applying the display filters affects the final results. | ||
+ | * (jreese) Any plugins that have order sensitivity should define a dependency on appropriate plugins. (jreese) | ||
* (vboctor): Default event - With the default events, how are you going to handle the return values returned by all these plug-ins? | * (vboctor): Default event - With the default events, how are you going to handle the return values returned by all these plug-ins? | ||
+ | * (jreese) The default event type will have each plugin run independent of each other, all given the same parameters. | ||
* (vboctor): How is the admin going to enable/ | * (vboctor): How is the admin going to enable/ | ||
+ | * (jreese) The manage plugins interface allows an admin to install/ | ||
* (vboctor): Some plug-ins may like to change the terminology of Mantis, for example, use ' | * (vboctor): Some plug-ins may like to change the terminology of Mantis, for example, use ' | ||
+ | * (jreese) In this case, it should be perfectly feasible for a plugin to register a callback for the PLUGIN_INIT event that does nothing but force a lang_load() of the appropriate strings files in the plugin' | ||
* (vboctor): We need to rationalize how custom functions / plug-ins will overlap. | * (vboctor): We need to rationalize how custom functions / plug-ins will overlap. | ||
+ | * (jreese) I believe the best way to handle this is to market plugins as ways to **enhance** Mantis, not to change how its core functionality works, which is what custom functions should do (and should still do). | ||
* (vboctor): I would love to allow the development of Mantis Packs which provide a way to develop a plugin that makes Mantis work better with a certain development process (e.g. scrum) or work better for users migrating their installations from a specific bug tracker (for example, the statuses, reports, custom fields, etc). | * (vboctor): I would love to allow the development of Mantis Packs which provide a way to develop a plugin that makes Mantis work better with a certain development process (e.g. scrum) or work better for users migrating their installations from a specific bug tracker (for example, the statuses, reports, custom fields, etc). | ||
+ | * (jreese) Certainly any plugin could easily do nothing but provide pages that allow for migrating or exporting data. Integration with other applications would be trickier, but the key way to allow this is by providing a smart and useful array of events for plugins to hook into. | ||
* (vboctor): We need to support attachment preview plug-ins. | * (vboctor): We need to support attachment preview plug-ins. | ||
+ | * (jreese) I think this would be better added as a core feature. | ||
* (vboctor): We need to allow plug-ins to add new blocks to pages like issue view, update, etc. | * (vboctor): We need to allow plug-ins to add new blocks to pages like issue view, update, etc. | ||
+ | * (jreese) Easily allowed by placing appropriate output type events in view pages. | ||
* (vboctor): It should be easy to develop features like Twitter notifications as plug-ins. | * (vboctor): It should be easy to develop features like Twitter notifications as plug-ins. | ||
+ | * (jreese) Once again, this comes down to picking appropriate and useful events. | ||
+ | * (DGtlRift): In the above explanation and examples should '' |
mantisbt/dynamic_plugin_requirements.1193603996.txt.gz · Last modified: 2008/10/29 04:31 (external edit)