The TWiki Plugin APIThe Application Programming Interface (API) for TWiki Plugins provides the specifications for hooking into the core TWiki code from your external Perl Plugin module.Available Core FunctionsThe TWikiFuncDotPm module (lib/TWiki/Func.pm ) describes all the interfaces available to Plugins. Plugins should only use the interfaces described in this module.
Note: If you use other core functions not described in Func.pm , you run the risk of creating security holes. Also, your Plugin will likely break and require updating when you upgrade to a new version of TWiki.
Predefined HooksIn addition to TWiki core functions, Plugins can use predefined hooks, or callbacks, as described in thelib/TWiki/Plugins/EmptyPlugin.pm module.
Hints on Writing Fast Plugins
Plugin Version DetectionTo eliminate the incompatibility problems bound to arise from active open Plugin development, a Plugin versioning system is provided for automatic compatibility checking.
Security
Creating PluginsWith a reasonable knowledge of the Perl scripting language, you can create new Plugins or modify and extend existing ones. Basic plug-in architecture uses an Application Programming Interface (API), a set of software instructions that allow external code to interact with the main program. The TWiki Plugin API Plugins by providing a programming interface for TWiki.Anatomy of a PluginA basic TWiki Plugin consists of two elements:
MyFirstPlugin topic. Other needed Perl code is best placed in a lib/TWiki/Plugins/MyFirstPlugin/ directory.
The Plugin API handles the details of connecting your Perl module with main TWiki code. When you're familiar with the Plugin API, you're ready to develop Plugins.
Creating the Perl ModuleCopy filelib/TWiki/Plugins/EmptyPlugin.pm to <name>Plugin.pm . The EmptyPlugin.pm module contains mostly empty functions, so it does nothing, but it's ready to be used. Customize it. Refer to the Plugin API specs for more information.
If your Plugin uses its own modules and objects, you must include the name of the Plugin in the package name. For example, write Package MyFirstPlugin::Attrs; instead of just Package Attrs; . Then call it using:
use TWiki::Plugins::MyFirstPlugin::Attrs; $var = MyFirstPlugin::Attrs->new(); Measuring and Improving the Plugin PerformanceA high quality Plugin performs well. You can use the TWiki:Plugins.PluginBenchmarkAddOn to measure your TWiki:Plugins.PluginBenchmarks. The data is needed as part of the Documentation Topic. See also Hints on Writing Fast Plugins.Writing the Documentation TopicThe Plugin documentation topic contains usage instructions and version details. It serves the Plugin files as FileAttachments for downloading. (The doc topic is also included in the distribution package.) To create a documentation topic:
OUTLINE: Doc Topic Contents Packaging for DistributionThe TWiki:Plugins.BuildContrib is a powerful build environment that is used by the TWiki project to build TWiki itself, as well as many of the Plugins. You don't have to use it, but it is highly recommended! If you don't want (or can't) use the BuildContrib, then a minimum Plugin release consists of a Perl module with a WikiName that ends inPlugin , ex: MyFirstPlugin.pm , and a documentation page with the same name(MyFirstPlugin.txt ).
Publishing for Public UseYou can release your tested, packaged Plugin to the TWiki community through the TWiki:Plugins web. All Plugins submitted to TWiki.org are available for download and further development in TWiki:Plugins/PluginPackage. Publish your Plugin by following these steps:
Recommended Storage of Plugin Specific DataPlugins sometimes need to store data. This can be Plugin internal data such as cache data, or data generated for browser consumption such as images. Plugins should store data using TWikiFuncDotPm functions that support saving and loading of topics and attachments.Plugin Internal DataYou can create a Plugin "work area" using theTWiki::Func::getWorkArea() function, which gives you a persistant directory where you can store data files. By default they will not be web accessible. The directory is guaranteed to exist, and to be writable by the webserver user. For convenience, TWiki::Func::storeFile() and TWiki::Func::readFile() are provided to persistently store and retrieve simple data in this area.
Web Accessible DataTopic-specific data such as generated images can be stored in the topic's attachment area, which is web accessible. Use theTWiki::Func::saveAttachment() function to store the data.
Recommendation for file name:
TWiki::Func::saveAttachment() function to store the data.
Recommendation for file names in Plugin attachment area:
Maintaining PluginsDiscussions and Feedback on PluginsEach published Plugin has a Plugin development topic on TWiki.org. Plugin development topics are named after your Plugin and end inDev , such as MyFirstPluginDev . The Plugin development topic is a great resource to discuss feature enhancements and to get feedback from the TWiki community.
Maintaining Compatibility with Earlier TWiki VersionsThe Plugin interface (TWikiFuncDotPm functions and handlers) evolve over time. TWiki 4.0 introduced new API functions to address the needs of Plugin authors. It also deprecated some functions. Some Plugins written for earlier TWiki releases using unofficial TWiki internal functions no longer work on the TWiki 4.0 codebase. All this means that some Plugins need to be updated to work on the TWiki 4.0 codebase. Organizations typically do not upgrade to the latest TWiki for many months. However, many administrators still would like to install the latest versions of a Plugin on their older TWiki installation. This need is fullfilled if Plugins are maintained in a compatible manner. Tip: Plugins can be written to be compatible with older and newer TWiki releases. This can be done also for Plugins using unofficial TWiki internal functions of an earlier release that no longer work on the latest TWiki codebase. TWiki:TWiki.TWikiPluginsSupplement#MaintainPlugins has more.Handling deprecated functionsFrom time-to-time, the TWiki developers will add new functions to the interface (either to TWikiFuncDotPm, or new handlers). Sometimes these improvements mean that old functions have to be deprecated to keep the code manageable. When this happens, the deprecated functions will be supported in the interface for at least one more TWiki release, and probably longer, though this cannot be guaranteed. When a plugin defines deprecated handlers, a warning will be shown in the list generated by %FAILEDPLUGINS%. Admins who see these warnings should check TWiki.org and if necessary, contact the plugin author, for an updated version of the plugin. Updated plugins may still need to define deprecated handlers for compatibility with old TWiki versions. In this case, the plugin package that defines old handlers can suppress the warnings in %FAILEDPLUGINS%. This is done by defining a map from the handler name to theTWiki::Plugins version in which the handler was first deprecated. For example, if we need to define the endRenderingHandler for compatibility with TWiki::Plugins versions before 1.1, we would add this to the plugin:
package TWiki::Plugins::SinkPlugin; use vars qw( %TWikiCompatibility ); $TWikiCompatibility{endRenderingHandler} = 1.1;If the currently-running TWiki version is 1.1 or later, then the handler will not be called and the warning will not be issued. TWiki with versions of TWiki::Plugins before 1.1 will still call the handler as required.
Related Topics: DeveloperDocumentationCategory, AdminDocumentationCategory, TWiki:TWiki.TWikiPluginsSupplement
-- Contributors: TWiki:Main.PeterThoeny, TWiki:Main.AndreaSterbini, TWiki:MainMikeMannix, TWiki:CrawfordCurrie
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||