r11 - 04 May 2006 - 00:21:50 - SamHaslerYou are here: TWiki >  Codev Web > TWikiRoot > LibDir > TWikiDir > PluginsDotPm
Tags:
, create new tag

Module name TWiki::Plugins PluginsDotPm
Location TWIKIROOT/lib/TWiki/Plugins.pm
Summary this is the plugin discoverer, loader and runner
Primary Author AndreaSterbini
CVS history CVS:lib/TWiki/Plugins.pm
CVS alpha CVSget:lib/TWiki/Plugins.pm
Contributing authors (see CVS History)
Is Class NO
First Release to be filled out
File Hierarchy
  TWIKIROOT
  lib
  TWiki
  Plugins.pm

Please see CodevDocumentationProject and CodevDocumentationProjectDev for comments on the format of these pages.

Purpose

To dicover, load, initialize and run all the plugins.

Used by

This module is primarily used to expose several hooks during several phases of the twiki execution.

Callback handlers with version

The column Version shows when the handler has been introduced.

Existing Plugin Hooks in latest Alpha

$VERSION Hook parameters Description
1.000 InitPlugin? $topic, $web, $user, $installWeb Called once at startup as the plugin system is initialised
1.010 RegistrationHandler $webName, $wikiName, $loginName Called from register script. Can be used for sending cookies, (UserCookiePlugin) or any other SessionPlugin processing
1.000 CommonTagsHandler $text, $topic, $web Called once per line of the text
1.000 StartRenderingHandler? $text, $topic, $web, $meta Called just prior to the mainloop
1.000 OutsidePREHandler $text, $web Called once per line, before any changes - as long as outside PRE & verbatim
1.000 InsidePREHandler? $text, $web Called after closing any lists when in a PRE or VERBATIM area, before any other changes
1.000 EndRenderingHandler? $text, $topic, $web Called after almost all modifications to a topic - ie this is the result of getRenderedVersion. <nop> tags are removed after this
1.010 BeforeEditHandler $text, $topic, $web Called when the text is edited to allow pre-processing of edited text. See TranslateTagPlugin
1.010 AfterEditHandler $text, $topic, $web Called when the text is previewed (or checkpoint-saved) to allow post-processing of edited text
1.010 BeforeSaveHandler $text, $topic, $web BeforeSaveHandler
1.010 WriteHeaderHandler? $query Called just prior to writing header. Returns a single result: a string containing HTTP headers, delimited by CR/LF and with no blank lines. If returns FALSE, the default header gets written. Plugin generated headers may be modified by core code before they are output, to fix bugs or manage caching. Plugins should no longer write headers to standard output.
1.010 RedirectCgiQueryHandler $query, $url Generic Hook into the redirect functionality.
1.010 GetSessionValueHandler? $key Called to get a session value... Used perhaps in a plugin..?
1.010 SetSessionValueHandler? $key, $value Called to set a session value... Used perhaps in a plugin..?
1.023 BeforeAttachmentSaveHandler \%attachAttributes, $topic, $web Called before an attachment is saved
1.023 AfterAttachmentSaveHandler \%attachAttributes, $topic, $web Called after an attachment is saved
????? BeforeCommonTagsHandler $text, $topic, $web Callback at the very beginning of the common tags handler; needed for Plugin that caches variables

See PluginHandlersProposed for handlers that have been suggested but not implemented, and TWiki.InstalledPlugins for hooks and handlers active on TWikiDotOrg.

Note: Below documentation is extracted from the currently installed TWiki:: Perl module, which is done by the PerlDocPlugin

package TWiki::Plugins

This module defines the singleton object that handles Plugins loading, initialization and execution.

This class uses Chain of Responsibility (GOF) pattern to dispatch handler calls to registered plugins.

Note that as of version 1.026 of this module, TWiki internal methods are no longer available to plugins. Any calls to TWiki internal methods must be replaced by calls via the $SESSION object in this package, or via the Func package. For example, the call:

should be replaced with

and the call

should be replaced with

Methods in other modules such as Store must be accessed through the relevant TWiki sub-object, for example

should be replaced with

$TWiki::Plugins::SESSION->{store}->saveTopic(...)

Note that calling TWiki internal methods is very very bad practice, and should be avoided wherever practical.

The developers of TWiki reserve the right to change internal methods without warning, unless those methods are clearly marked as PUBLIC. PUBLIC methods are part of the core specification of a module and can be trusted.

PUBLIC constant $VERSION

This is the version number of the plugins package. Use it for checking if you have a recent enough version.

PUBLIC $SESSION

This is a reference to the TWiki session object. It can be used in plugins to get at the methods of the TWiki kernel.

You are highly recommended to only use the methods in the Func? interface, unless you have no other choice, as kernel methods may change between TWiki releases.

ClassMethod new( $session )

Construct new singleton plugins collection object. The object is a container for a list of plugins and the handlers registered by the plugins. The plugins and the handlers are carefully ordered.

ObjectMethod load($allDisabled) -> $loginName

Find all active plugins, and invoke the early initialisation. Has to be done after prefs are read.

Returns the user returned by the last initializeUserHandler to be called.

If allDisabled is set, no plugin handlers will be called.

ObjectMethod settings()

Push plugin settings onto preference stack

ObjectMethod enable()

Initialisation that is done after the user is known.

ObjectMethod getPluginVersion() -> $number

Returns the $TWiki::Plugins::VERSION number if no parameter is specified, else returns the version number of a named Plugin. If the Plugin cannot be found or is not active, 0 is returned.

ObjectMethod addListener( $command, $handler )

   * =$command* - name of the event
   * =$handler= - the handler object.

Add a listener to the end of the list of registered listeners for this event. The listener must implement invoke($command,...), which will be triggered when the event is to be processed.

ObjectMethod haveHandlerFor( $handlerName ) -> $boolean

   * =$handlerName= - name of the handler e.g. preRenderingHandler
Return: true if at least one plugin has registered a handler of
this type.

ObjectMethod registrationHandler ()

Called by the register script

ObjectMethod beforeCommonTagsHandler ()

Called at the beginning (for cache Plugins only)

ObjectMethod commonTagsHandler ()

Called after %INCLUDE:"..."%

ObjectMethod afterCommonTagsHandler ()

Called at the end (for cache Plugins only)

ObjectMethod preRenderingHandler( $text, \%map )

   * =$text= - the text, with the head, verbatim and pre blocks replaced with placeholders
   * =\%removed= - reference to a hash that maps the placeholders to the removed blocks.

Placeholders are text strings constructed using the tag name and a sequence number e.g. 'pre1', "verbatim6", "head1" etc. Placeholders are inserted into the text inside \1 characters so the text will contain \1_pre1\1 for placeholder pre1.

Each removed block is represented by the block text and the parameters passed to the tag (usually empty) e.g. for

 <pre class='slobadob'> XYZ </pre> the map will contain: <pre> $removed->{'pre1'}{text}:   XYZ $removed->{'pre1'}{params}: class="slobadob" </pre> 

Iterating over blocks for a single tag is easy. For example, to prepend a line number to every line of a pre block you might use this code:

foreach my $placeholder ( keys %$map ) { if( $placeholder =~ /^pre/i ) { my $n = 1; $map->{$placeholder}{text} =~ s/^/$n++/gem; } }

ObjectMethod postRenderingHandler( \$text )

   * =\$text= - a reference to the HTML, with the head, verbatim and pre blocks replaced with placeholders

ObjectMethod startRenderingHandler ()

Called just before the line loop

DEPRECATED Use preRenderingHandler instead. This handler correctly handles verbatim and other TWiki ML block types, and exposes them to the plugin.

ObjectMethod outsidePREHandler ()

Called in line loop outside of <PRE> tag

DEPRECATED Use preRenderingHandler instead. This handler correctly handles pre and other TWiki ML block types, and is called only once instead of line-by-line.

ObjectMethod insidePREHandler ()

Called in line loop inside of <PRE> tag

DEPRECATED Use preRenderingHandler instead. This handler correctly handles pre and other TWiki ML block types, and is called only once instead of line-by-line.

ObjectMethod endRenderingHandler ()

Called just after the line loop

DEPRECATED Use postRenderingHandler instead.

ObjectMethod beforeEditHandler ()

Called by edit

ObjectMethod afterEditHandler ()

Called by edit

ObjectMethod beforeSaveHandler ()

Called just before the save action

ObjectMethod afterSaveHandler ()

Called just after the save action

ObjectMethod afterRenameHandler ( $oldWeb, $oldTopic, $oldAttachment, $newWeb, $newTopic, $newAttachment )

Called just after the rename/move/delete action of a web, topic or attachment.

   * =$oldWeb= - name of old web
   * =$oldTopic= - name of old topic (empty string if web rename)
   * =$oldAttachment= - name of old attachment (empty string if web or topic rename)
   * =$newWeb= - name of new web
   * =$newTopic= - name of new topic (empty string if web rename)
   * =$newAttachment= - name of new attachment (empty string if web or topic rename)

ObjectMethod mergeHandler ()

Called to handle text merge.

ObjectMethod beforeAttachmentSaveHandler ( $attrHashRef, $topic, $web )

This code provides Plugins with the opportunity to alter an uploaded attachment between the upload and save-to-store processes. It is invoked as per other Plugins. * $attrHashRef - Hash reference of attachment attributes (keys are indicated below) * $topic - | Topic name * $web - | Web name

Keys in $attrHashRef: | Key | Value | | attachment | Name of the attachment | | tmpFilename | Name of the local file that stores the upload | | comment | Comment to be associated with the upload | | user | Login name of the person submitting the attachment, e.g. 'jsmith' |

Note: All keys should be used read-only, except for comment which can be modified.

Example usage:

    my( $attrHashRef, $topic, $web ) = @_;    $$attrHashRef{'comment'} .= " (NOTE: Extracted from blah.tar.gz)"; 

ObjectMethod afterAttachmentSaveHandler( $attachmentAttrHash, $topic, $web, $error )

deal with an uploaded attachment between the upload and save-to-store processes. It is invoked as per other plugins.

   * =$attrHashRef= - Hash reference of attachment attributes (keys are indicated below)
   * =$topic= -     | Topic name
   * =$web= -       | Web name
   * =$error= -     | Error string of save action, empty if OK

Keys in $attrHashRef: | Key | Value | | attachment | Name of the attachment | | tmpFilename | Name of the local file that stores the upload | | comment | Comment to be associated with the upload | | user | Login name of the person submitting the attachment, e.g. 'jsmith' |

Note: The hash is read-only

ObjectMethod writeHeaderHandler () -> $headers

Called by TWiki::writePageHeader. DEPRECATED do not use!

DEPRECATED Use modifyHeaderHandler instead. it is a lot more flexible, and allows you to modify existing headers as well as add new ones. It also works correctly when multiple plugins want to modify headers.

ObjectMethod modifyHeaderHandler ( \@headers, $query )

ObjectMethod redirectCgiQueryHandler () -> $result

Called by TWiki::redirect

ObjectMethod renderFormFieldForEditHandler ( $name, $type, $size, $value, $attributes, $possibleValues ) -> $html

This handler is called before built-in types are considered. It generates the HTML text rendering this form field, or false, if the rendering should be done by the built-in type handlers. * $name - name of form field * $type - type of form field * $size - size of form field * $value - value held in the form field * $attributes - attributes of form field * $possibleValues - the values defined as options for form field, if any. May be a scalar (one legal value) or an array (several legal values) Return HTML text that renders this field. If false, form rendering continues by considering the built-in types.

Note that a common application would be to generate formatting of the field involving generation of javascript. Such usually also requires the insertion of some common javascript into the page header. Unfortunately, there is currently no mechanism to pass that script to where the header of the page is visible. Consequentially, the common javascript may have to be emitted as part of the field formatting and might be duplicated many times throughout the page.

ObjectMethod renderWikiWordHandler () -> $result

Change how a WikiWord is rendered

Originated from the TWiki:Plugins.SpacedWikiWordPlugin hack

Contributors:
-- MartinCleaver - 23 Jun 2002
-- AndreaSterbini - 12 Sep 2003
-- PeterThoeny - 02 Feb 2004

Discussions

Has anyone noticed that a plugin does no know what version of a topic it is looking at? I'm going to add a $rev to the initPlugin in my test system, but even this is a continuation of a mess. To stop doing all this the hard way (I will need access to $meta, from 2-3 versions of a topic, and also know which i am displaying, and a few other things) I'd like to suggest that we begin looking at passing around a reference to a topic object. This TopicObject would contain references to all loaded information (as each version is loaded it is cached, and references to these cached bits are kept for the duration of the transaction (or more for mod_perl). Obviously there is a requested version/DateTime in this TopicObject? , which would also allow us to display an object as it was back then, rather than INCLUDEing current topics when showing a previous version of a topic.

This work is being done for my workplaces iso9001 web, and will probably be extended to indlude the idea of documentation versions.

-- SvenDowideit - 16 Apr 2004

Somehow, I like the idea of the TopicObject smile

Anyway, if the plugin has access to the topic metadata, then is pretty easy to get the information.

-- RafaelAlvarez - 24 Aug 2004

I was thinking about the current mechanism to handle the plugins. Right now it first scans the plugins to register the handlers that the plugin can use, and then it calls only those plugins that has the hook defined.

If the idea in RefactorPluginApi? of having a "Base Plugin" and make the other plugins to subclass it, then an improvement can be done: The base plugin could have an empty implementation of each handler, and for each hook call the handler in all the plugins. I have tested it, and the improve over calling an empty method over calling "defined &sub " is between 8% and 10% .

(more on that later)

-- RafaelAlvarez - 24 Aug 2004

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r11 < r10 < r9 < r8 < r7 | More topic actions
 
Powered by TWiki
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback SourceForge.net Logo