ZWiki uses the concept of "mixin" classes to extend code and add functionality. This works and is easy but is not a "plugin" in any real sense. One cannot add or remove mixin classes at runtime without modifying the code. The plugin system as currently (11/10/2004) implemented adds a fixed number (15) "mixin" parents to ZWikiPage.

I cannot imagine how one could add a "plugin" that modifies any ZWiki functionality at all.

I think the way forward is to define a ZWikiPluginAPI? with a set of callbacks, and define things Plugins can do. ZWiki should define a set of register... functions and a set of things a plugin can do. "mixin" classes are just not appropriate as plugins.


comments:

wrong name, useful bit -- Wed, 10 Nov 2004 17:54:33 -0800 reply
call the 11/10/2004 setup extensions or page utils. It is a handy orthogonal way to add page functionality.

The 15 limit just a number, set as you set the plug-ins and the j-script allow: A product level change.

wrong name, useful bit --Bob McElrath?, Wed, 10 Nov 2004 18:00:21 -0800 reply
I don't understand your comment...

wrong name, useful bit --DeanG, Wed, 10 Nov 2004 18:58:27 -0800 reply
What's in the current code that is called "plug-in" has use, although it may not follow the common expectations of a plug-in

To avoid confusion, and while it's in it's infancy, it may be useful to rename it and call later Plug-In functionality by that name.

I see three forms:

  1. Current: Mixin class adding page methods and render nuggets
  2. TWiki: Method within page text that includes parameters, which get passed to some other method for render goodness.
  3. Product-Plug-in: Chunk-o-code which can redefine, extend, or add functionality to an existing Zwiki.

wrong name, useful bit --Bob McElrath?, Wed, 10 Nov 2004 19:47:53 -0800 reply
Good idea...

Also I don't want it to sound so much like I'm disparaging the current code...

DeanG [zwiki-wiki@zwiki.org]? wrote:

What's in the current code that is called "plug-in" has use, although it may not follow the common expectations of a plug-in

To avoid confusion, and while it's in it's infancy, it may be useful to rename it and call later Plug-In functionality by that name.

Simon: what was the point of separating the stuff in plugins/? What makes those files different from the mixin clases in the parent directory?

I see three forms:

  1. Current: Mixin class adding page methods and render nuggets

But everything is a mixin class...what makes the contents of plugins/ different from UI.py or Comments.py or ...

2. TWiki: Method within page text that includes parameters, which get passed to some other method for render goodness.

I propose RenderingPlugin?. I don't like these because it is pagetype specific. For instance Fit can only work on a pagetype that supports HTML, and cannot work on reST or Textile. So, really, it's a pagetype plugin.

The StructuredText infrastructure or docutils infrastructure are well-set-up for this kind of plugin, but it would be almost impossible to write a plugin that could work for both.

3. Product-Plug-in: Chunk-o-code which can redefine, extend, or add functionality to an existing Zwiki.

Extension?