There are several issues i'd like to address using zwiki variants, but at the moment i don't really know a clever way how to keep those (to be developed variants) up to date with general zwiki development. The same problem applies when maybe some of the variations should be included in original zwiki.

I think it's time to start some discussion on refactoring zwiki code and before doing that on zwiki architecture in general.

In my eyes zwiki is / should become the zope based wiki application plattform. This means while keeping wikiwebs simple for users considerable effort should be taken in making zwiki a flexible and extensible tool that allows the easy integration of new functionality for developers and wikiadmins.

At the moment i think of wiki pages as documents of a certain type with some content that is presentable and editable through the web. On the other hand there is usefull additional functionality in wiki pages like pagehistory, context, accesscontrol, etc. Presentation and editing of content here is tied closely to piping content through various filters.

To make zwiki flexible and extensible i'd like the zwiki page object to be very slim and functionality to be separated from it.

OK, here is a first zwiki page vision (without additional functionality) :

 wikipage with properties wikipage_type (string)
                          display_filters      (list of strings)
                          checkout_filters     (list of strings)
                          checkin_filters      (list of strings)

wikipage_type: determins which dtml-templates to use for presentation and editing. (Current wikipages would get the type standard_wiki_page which triggers presentation with standard_wiki_header, standard_wiki_footer and page creation with standard_wiki_content (now standard wiki_page) )

display_filters: holds a list of filters to be applied to the wiki page (wiki_header + wiki_content + wiki_footer) before handing them over to the browser for presentation. (Currently this is controled by the page_type property)

checkout_filters: holds a list of filters to be applied to content before inserting it into the editform on the editpage. (Not possible in the current zwiki implementation i think)

checkin_filters: holds a list of filters to be applied to edited_content before storing it as content of a wikipage. (Not possible in the current zwiki implementation either i think)

I believe this architecture to be quite useful, as it allows filters to be implemented as dtml, python, external or whatever methods and giving wikiadmins control over which filters to apply.

I think additional functionality could be seperated from the wikipage object itself by implementing them as some kind of mixinclasses and/or providing hooks for presentation, checkout and checkin processes.

--BeWo 28.02.2001

Thanks for starting this page. Good food for thought above - care to hack up a prototype ? :). By the way, I'm thinking that we should aim to release the current version + bugfixes as 1.0, include some or all wikifornow enhancements in 1.1+, and call the radically-refactored version 2.x. Comments ? --SM

Sounds good! And yes i am willing to hack up a prototype. On the other hand willingness is to some degree dependent on if my company is willing to let me do it. I could even think about investing some of my spare time, but there is none. By the way i'm very pleased to see you interested as i dislike the idea of branching one more wiki engine from your source. --BeWo

Here we are! I just finished a rendering mode called filtered for Zwiki. If Simon is willing to include the code, it could be a first step in refactoring zwiki. The rendermode implements the display_filter part mentioned above (those were called presentation_filters, but that's too long a word). See PageTypeFiltered for more information --BeWo 29mar2001 :)

What a tease.

See also ZwikiOneDesignNotes. Some more scribblings from the whiteboard:

many (all ?) object types can render/be edited/navigated as wiki pages (make Wikipage a mix-in ?). Alternate management interface. Blur enforced code/data distinction further. Two render modes needed (edit executable content, run executable content). --SM

Wikipage mixin? sounds frightening funny! i experimented in making a filtered mixin class but failed, hope i'll recover and realize it some time. filtering would be interesting for non wiki stuff, there is a proposel on this issue somewhere at

To get in touch with code/data destinction read up on literate programming concepts or wait for the WikiBasedLiterateProgramming page --BeWo

See also: TheReformSociety:ZptWiki

See also: TheReformSociety:ZptWiki --2003/03/06 19:42 GMT
See also: TheReformSociety:ZptWiki