create new tag
, view all tags
Enhancing the Plugin handling is a focus of the BeijingRelease. The idea is to let plugins have more control over TWiki so that advanced Plugins (like for example a SpellChecker) can be created without changing the core code (aka without involving the CoreTeam). KISS is key, what we want is more power but less complexity, which can be challenging to design.

This is currently at the brainstorming stage. What kind of functionality do we need to provide? I.e.

-- PeterThoeny - 17 Dec 2001

See IncludedTopicVariableNeeded for issues with plugins and includes. I think there is a need for more state information for included files. Maybe an @INCLUDED_FILES array that is visible to the plugins so that plugins like % COMMENT% can find out if they should display, or what file their anchor point is in.

-- JohnRouillard - 18 Dec 2001

We need a cleaner way to get topic text back from a Java applet.

All the work currently done in the edit and preview scripts should be refactored, modularised and made accessible to addons. I've had to hack round this twice now, in ActionTrackerPlugin/editaction and PowerEditAddon.

-- CrawfordCurrie - 27 Feb 2002

I'm personally very impressed with the TWikiDrawPlugin because of it's BlackBox nature.

Drawing is not editable here (insufficient permission or read-only site)

As mentioned above though, 'we need a cleaner way to get topic text back' appears to me as key.

The tables % TABLE{mynewtable}% and form % FORM{mynewform}% plugins could be very powerful if there was an xml interface for storage and manipulation. There are MANY xml editors now available that could be easily modified to operate in an applet environment.

I am not a programmer wink but I know that when there is seperation of logic and data the applications are easier to manipulate and modify.

xybrix at www.jbrix.org offers a lightweight powerful architecture for tables and forms. It is also reads and writes xml in 'generating' custom forms written in xml. It also has the added advantage of having implemented some of the xform spec. http://www.w3.org/MarkUp/Forms/

Of note there is also http://xform.nanoworks.org/ which aims specifically at creating forms for the web.

Whatever the PluginHandlingDescription looks like, I believe making it as easy as this % PLUGIN% with % XMLPluginConfigure% (pop up to fill in the required variables) is a simple user focused interface for EnhancedPluginHandling.

Drawing is not editable here (insufficient permission or read-only site)

with the power of reading an xml interface from an applet or from the user directory, is important from a user's perspective.I should do a user story wink -- DennisDaniels - 21 Mar 2002

Please take a look at HowDoesTWikiKnowWhichPluginToCall for an idea I had wrt to plugins.

-- DavidLeBlanc - 19 Mar 2002

See Also XmlRpc

-- YAML (http://www.yaml.org) has a simplistic (readable) markup while retaining full power of XML. The APIs in perl (and python, Java etc.) directly map the XML structures to the native data structures.

-- VinodKulkarni - 06 Sep 2002

I am considering some EnhancementsToThePluginAPI

-- AndreaSterbini - 25 Mar 2002

I'm concerned with twiki performance when bogged down by plugins, all the hooks added means that the rendering of every topic has to go through a miriad plugins before it can be rendered. I have taken out plugins from my site due to this performance issue.

So, why not have a cached plugin usage for each topic (as part of its metadata)?, which can be generated on every (infrequent) topic save, and is used on topic rendering to determine which plugins to call.

Granted, there are plugins that would need to see every topic (I can't think of an example, but you know who you are wink ), so this should be specified as a plugin variable as part of the plugin page or plugin initialization.

-- EdgarBrown - 06 Sep 2002

An example of a plugin that should see every topic would be RicherSyntaxPlugin, as it adds additional rules that are not easily picked out otherwise...

-- ThomasWeigert - 03 Nov 2002

I see this topic is still listed as included for BeijingRelease, but I havent seen any real formal specs on what it is exactly.

I would like to lobby for 2 things as part of the plugins enhancements for Beijing and leave the rest to subsequent releases.

  • Finish the onSave hook. It was documented in the last release, lets just make sure the implementation is there. Ill also admit I have a selfish interest in using it to store stuff to a local SQLite db.
  • Implement some type of basic builtin profiling (Think DBI::Profile). Im envisioning something like logging the amount of time it takes to init each plugin, amount of time in each "hook" for every topic rendered. Once we have all the data in front of us as to which plugins are hogs, etc we can then begin the investigative process as to how to improve performance while enhancing the capabilities of plugins framework.

-- JohnCavanaugh - 30 Nov 2002

I would like to see as much of the current text formatting rules as possible moved from the core TWiki.pm to a plugin, perhaps DefaultPlugin, and then the legacy, backwards-compatible formatting rules in DefaultPlugin can be moved to a LegacyPlugin? This would make it so much easier for people who don't like the default TWiki text formatting rules for definition lists and headings.

-- AdamTheo - 10 Dec 2002

JohnCavanaugh: any chance of you contributing a patch that finishes onSave hook?

-- MartinCleaver - 21 Dec 2002

Hi all, I need your comments on the following suggestions :

calling plugins:

  • at first time a topic is rendered (or even better at store time ?) one could put some META TAG(s) (in each topic) specifying wich plugins have to be called to render the topic:
  • perhaps a method/function (initPlugin ?) in each plugin could give the following informations:
    • should the plugin be called on the topic ?
    • when should it be called (what handler ? )
At view time, call only the plugins specified in the META TAG(s)

To keep the already existing plugin working one could perhaps use a new directory for the modified/new plugins and use the plugins in the "PLugin' directory as before and the one in the new directory using the new way.

caching plugins rendering

having implemented the above one could perhaps add some caching mechanism to keep the rendered topic or only part of the rendering in an other file using a different file extension (or even an other directory). Again, using some META TAGs and the initPlugin function/method to return a cachable, notcachable info (if the plugin is only using that single topic caching is possible if it is using other topics too it is not cachable). At view time render the cached version of a topic if it exist and the 'normal' version if not.

Here my questions :

  • what can be implemented ?
  • what module(s) have to be modified ?
  • could templates be cached using an identical way ?
  • should a mechanism be implemented to expire the cache after a certain amount of time , periodically or at request (using a menu)?

Thank you.

-- MarcelTrap - 27 Dec 2002

Caches are difficult beasts, they add considerable complexity in return for speed. So far I've found the speed of TWiki acceptable, so have not been tempted to implement a cache. In the above I assume a topic would list plugins that didn't affect it (as well as ones that did), so that new plugins would try (could use a timestamp, but this could be messy. What would happen if a plugin was changed e.g. a new smilie added to the config page for the Smilie Plugin?

-- JohnTalintyre - 27 Dec 2002

Thank you for the quick reply, I am quite new to twiki and so do not understand all of the issues and even do not use the proper 'words' perhaps. Somehow I understood that all the plugins get called on any topic ? The first idea was to only call the 'needed plugins' for each single topic:

  • at 'save time' find some way to put for instance something like
META:plugins(calendarPlugin,otherPlugin,thirdPlugin,...)% where only the plugin needed for rendering the topic would be listed.

  • at 'view time' only call the plugin listed in that META tag.
Each time the topic is modified that META:plugins tag gets rewritten.

Additionaly there is, what I was calling 'caching' but probably should have used pre-rendering or pre-expending of variables. It looked simple too me (but again I am new...):

  • any variable than can be 'expanded' by a Pluging for a 'long time' ( probably only the one operating on 1 topic ) , until the topic is modified again, could be kept 'expanded' in an other file (with the extension .pre for instance). The topic.pre file would be an exact copy of what is in the topic.txt file. The only difference being the (pre)expanded variable and the META:plugins tag where some of plugin could be removed from META:plugins tag as they already 'finished' their work.
That way even less plugins are called each time the topic is viewed.

Your remarks:

  • speed: yes the speed is good for me ( I am the only user, I have not convinced any of my collegues yet, will keep trying ...) as I have not installed many plugins. But more time consuming plugins GraphPlugin, GaugePlugin, WebDot or perhaps an interface to Ploticus ( http://ploticus.sourceforge.net ) would benefit of some kind of pre-rendering ?

  • list of plugin: Only plugins that do affect a topic need/should be listed in the META:Plugins tag

  • Smilie:
    • if a new smilie is added in the config page - no trouble it can not be in use in the topic until somebody modifies the topic what would recreate the topic.pre file.
    • if a smilie is modified (in the config page) and being used in the topic, yes one would get the pre-rendered (old) version of the smilie., hence the need to 'expire' (remove) the topic.pre file by some means. For this case of smilie once a day would be acceptable (for me wink ,may be not for others ? ).

For other more crucial plugin a much shorter period would be used or even not allow the pre-rendering. The period could be a preference variable (PLUGIN_PREEXPIRE=minuts) for each plugin specifying how many minutes a topic.pre is valid after the rendering. One could think about an META:expire(date=ddmmyyyy) tag in the topic.pre file. the date could be calculated like Date_rendered + smallest(PLUGIN_PREEXPIRE) among all the plugin used(pre-expanded) in the topic.pre.pre file.

-- Main.Marcel.Trap - 28 Dec 2002

This topic is too broad for the BeijingRelease. Lets narrow it down to what is feasible with little effort: PluginApiForTopicHandling

-- PeterThoeny - 29 Dec 2002

BeijingRelease links to this page in it's top release goals, yet it's only a "nice to have" with spec status at 50%, implementation status at 10% and documentation status at 0%. It looks like these need to be updated. Perhaps the release goals and tracking item should link directly to PluginApiForTopicHandling? I've also taken the liberty of updating this topic's WebForm field of ImplementationDate to TWikiBetaRelease.

-- GrantBow - 06 Jan 2003

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdraw blacbox.draw r1 manage 2.7 K 2002-03-19 - 09:55 DennisDaniels  
GIFgif blacbox.gif r1 manage 6.8 K 2002-03-19 - 09:55 DennisDaniels  
Unknown file formatdraw mydrawing.draw r5 r4 r3 r2 r1 manage 1.5 K 2002-11-20 - 15:00 SaschaLosko  
GIFgif mydrawing.gif r5 r4 r3 r2 r1 manage 4.7 K 2002-11-20 - 15:00 SaschaLosko  
Edit | Attach | Watch | Print version | History: r23 < r22 < r21 < r20 < r19 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r23 - 2005-02-15 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.