What does this mean to ZWiki? To You?

DeanG I pretty much considered DTML'ing in of Zope products a PluginAPI?...but those aren't intertwined with ZWiki, or replacement parts.

The inspiration I see is a file manager, which would allow you to make a part of your page a file management tree. Key requirements being that that page comes up when a search containing a part of those filenames is done...or even the file itself (but probably not the contents.)

ThomasWeigert, 2002/12/11 01:18 GMT (via web):
A plugin API is a mechanism for extending Zwiki in a consistent manner.

I view Zwiki as primarily a mechanism of rendering text that has been written in some stylized form as an HTML page without (i) having the writer of that text write DHTML or HTML code but (ii) while still generating attractive and useful (for collaboration and information exchange) pages.

One can easily imagine sophisticated users wanting to extend the rendering engine in various ways (I'll list examples later). A plugin API would define a set of handlers that are called at predefined points during the rendering process that would allow the developer of addins to cause additional things to happen beyond the standard Zwiki behavior.

Other wikis, in particular Twiki (http://twiki.org) have used this vehicle to foster a whole community of developers of extended features (referred to as plugins).

Basic implementation vision? --DeanGoodmanson, 2003/04/02 00:25 GMT
I'd like to open the floor to this. I'm consistently disappointed with DTML product inclusion with zwiki (well, not that I got much farther than Poll & Calendar, but...)

The TWIiki? useage, %Plug-inName{ parameters/content/etc. }%, is simple enough to understand and teach, and potentially more straightforward than DTML. (And could we share some of those nifty plug-ins as Zope has Perl scriptability?)

%RESTTEXT{ This is rest text ================ I wish }%

<dtml-var "RestText?('text'=""" This is rest text ================ I wish """> (I realize I mucked up the dtml-params, and I frankly can never remember exactly how to do it without looking it up or hit-n-miss.) Questions:

  1. Is there a vision for this?: Use Plone/CMF plug-ins, then use a wiki for quick-n-dirty text already!
  2. I've consistently overlooked how the whole zwiki page type plug-in method works, and should re-evaluate.
  3. There's a vision and some slight implementation thoughts...

    a. DTML can be simplified.

    b. ZPT is the answer.

    c. Python scripts are the answer.

    d. The Twiki style could be implemented...here's what I was thinking....


I think the Plugin API is a great idea. Since we are using Python, we can avoid lots of legacy perl procedural cruft. This will make our job vastly easier. Here is my 2c:

  1. Define the binding times (currently I can see three: compile time, startup time, and render time)
  2. Understand the variabilities that may be bound at each binding time. (Lots of configuration variables, depending on the kind of plugin.)
  3. Define an API for each binding time. (in the following example, I have three: register, configure, and render)

For example, you might have a PluginRegistry singleton that enables plugins to register themselves at startup time. Each plugin might look something like this:

     from PluginRegistry import PluginRegistry

     def configure(dict):
        # load dictionary with configuration settings from a file or
        # default values in line

     class PieChartPlugin(ZWikiPlugin):

       def __init__(self):
           # superclass calls configure()

       def render(self, page):
           # return rendered result

    PluginRegistry.register("Render beautiful pie charts", PieChartPlugin)


UseMod? variant --DeanGoodmanson, Thu, 13 Nov 2003 13:51:17 -0800 reply
Saw the UseMod?'s !-- pragma system, and was intrigued, but not sure what to think of that.

I really need a plugin architecture for ZWiki -- Fri, 19 Mar 2004 15:45:04 -0800 reply
Is anybody developing a plugin architecture for ZWiki?

I really need a plugin architecture for ZWiki --Simon Michael, Fri, 19 Mar 2004 18:47:34 -0800 reply

Is anybody developing a plugin architecture for ZWiki?

No, no-one is. I have been thinking about it and would welcome any concrete ideas.

MoinMoin Plugin Architecture --GoofRider?, Thu, 27 May 2004 02:40:53 -0700 reply
MoinMoin has an excellent plugin architecture, divided into functional types (Actions, Processors, Macros, Parsers, etc.)

Personally, my biggest concern is the lack of includes in ZWiki, esp'ly when running inside Plone/CMF (when DTML is useless inside ZWiki pages). And alternative parser that support MoinMoin's syntax would also be a great addition, that would overcome all the shortcoming of STX in the short term.

MoinMoin Plugin Architecture --simon, Thu, 27 May 2004 08:16:08 -0700 reply
Plugins - thanks for the recommendation, I'll look at it.

There's no difference in DTML functionality in or outside CMF.

I don't know Moin's syntax too well, but my impression was that STX is light years ahead if anything. Tables, certainly.

MoinMoin Plugin Architecture -- Tue, 27 Jul 2004 19:41:51 -0700 reply
It seems like the author(s) of MoinMoin are thinking about implementing MoinMoin on top of Zope... maybe there is the possibility for a fruitful collaboration.

Wrap any document in Zwiki? --jeorgen, Fri, 17 Dec 2004 06:05:32 -0800 reply
I am not sure if this is the right page to post on, but I would like to see functionality in zwiki where I can make a zwiki link, and when creating the resulting page, choose between mnay documnet types, e.g. plone document types. These documents would be wrapped in some zwiki page api functionality. In this way I could type a link about, say, an appointment and in the following page (when creating the new zwiki page) select a Plone Event object. The event object would be wrapped so that it includes the zwiki navigational features (gui), and necessary methods and attributes (API).

Wrap any document in Zwiki? --Simon Michael, Tue, 21 Dec 2004 08:53:14 -0800 reply
I hear you.. but some would say things are confused enough already in the zwiki-plone world.

Another idea that comes up is to provide zwiki linking & functionality as an option for archetypes objects.

MoinMoin Plugin Architecture -- Sat, 29 Jan 2005 20:37:00 -0800 reply
Has there been any further developments on this front? I want to create an extension to the MoinMoin macro/parser/etc. architecture, but I would very much like to implement it over Zope (it merges naturally with a backing database, and the security features of Zope would help a lot).

MoinMoin Plugin Architecture --simon, Sun, 30 Jan 2005 16:13:20 -0800 reply
No further developments. I'm working on code cleanups which will help sooner or later.

Wrap any document in Zwiki? --simon, Sun, 30 Jan 2005 16:14:01 -0800 reply

Another idea that comes up is to provide zwiki linking & functionality as an option for archetypes objects.

NB someone did this recently, check the #plone log if there is one.

Ted Leung on Plugins --DeanG, Mon, 07 Mar 2005 07:11:25 -0800 reply
" The ability to extend allows you to build a base product with the feature set for the head. The extension mechanism(s) allow you or a third party to develop functionality for some constituency in the tail. " -- http://www.sauria.com/blog/2005/03/07#1238