This page is intended to be a discussion of implementing features such as ZwikiIssueTracker and ZwikiAndProjectManagement.

DeanGoodmanson, 2002/11/17 06:23 GMT (via web):
Abstract Thoughts

In pondering the ZwikiAndProjectManagement and other related features, I've come to the conclusion that most of my pipe dreams for extending ZWiki may be generalized into a common implementation of a ZwikiRecordBook.

Existing processes: Users start tracking items with a list, move it to a spreadsheet to do sorting and analysis, move it into a database when you need to share it with an extended group, and ultimately build a product around it. (Outliners fit in here somewhere...but not going to digress just yet.)

I propose that somewhere around or after the spreadsheet phase, you move that into a ZwikiDatatable?. *

What features are needed?

This kind of datatable seems to lend itself to blogs, calander events, task tracking, membership lists, inventories and other Team related activities.
Discernment for when to build a datatable or just use a page collections are based on the discernment between data and information, and the needs of analysis on that data. More rambling available if your interested in this potential debate.

I don't expect this could be built in a turnkey manner. For each item type a class zwikipage mixin and pagetype would need to be added to the ZWiki filesystem product, along with appropriate Properties and Catalog additions.

At this point I'd like to include a lot more product management-speak product/feature proposal details, rational, goals and scope, but no need to try to be comprehensive on a generalization. Details upon specific request and in the ensuring discussion.

Zwiki is cool because you can extend it. This is a starting point for extending it in an extremely lightweight database manner, leveraged upon ZwikiIssueTracker's successful proof of concept and pilot.

I expect it to keep in-line with KISS principles. For me, Zwiki is lightweight documentation and collaboratoin, and these tools would follow suit. Tools must be tailored to fit specific needs, thus the need to keep it simple for the sake of customization. Hopefully this is in-line with Wiki principles and will fend off product identity issues.

...* Why not a database? Too high of expectation, primarily RDMS features. Secondly normalization (beyond 1st normal form) need not apply. I'm not sure this would work with any type of dataset requiring more than 3 tiers in the organization.

A new name may be needed, as DataTable? is currently popular for a multi-row data view control.

Looking forward to your feedback, especially regarding technical and other implementation issues, and how this discussion/development's relationship with the code refactoring of ZwikiIssueTracker.

DeanGoodmanson, 2002/11/22 00:34 GMT (via web):
I don't think it's appropriate for comments. Possibly for a Threaded Discussion (ultra-lightweight Pipermail) and other filters which may make it worthwhile. I wouldn't expect the number of items/records in a ZwikiRecordBook to exceed 9999, and thus think it might still be a poor choice for a message board.

DeanGoodmanson, 2002/11/22 00:53 GMT (via web):
I didn't intend this as a ZWiki front end or wrapper for a Database, which is another reason the name should change, as Datatable GUI elements are usually that... ZwikiRecordBook ?

Using DBTab? to let ZWiki Front end a database is a very cool endeavor..perhaps theres some shared code involved, but out of the current scope of this "lightweight tool" thought.

DeanGoodmanson, 2002/11/24 02:17 GMT (via web):
Just came across Abracadabra Object for easy to build ZMI based objects+properties .

Seems like a possibility for intergrating with a zwiki, and/or something to be leveraged.

But then there's also more catalog issues... - DeanG

BillSeitz, 2002/11/25 13:57 GMT (via web):

What do you see as the main value of the zwiki codebase, vs just core Zope? Do you want your tracking tables to integrate with zwiki discussions, or do you just want an easy way to build forms? If the latter, other products might be a better fit.

Also, do you see a need for multiple types/tables per folder, or could you put each in a separate subfolder?

DeanGoodmanson, 2002/11/26 18:28 GMT (via web):
ZODB IndexedCatalog? looks like another tool for catalog's on a ZODB. Anyone used it within a Wiki? Seems like it might help here.

DeanGoodmanson, 2002/11/27 04:41 GMT (via web):
Values of tables in zwiki

>> What do you see as the main value of the zwiki codebase, vs just core Zope?

Integrating table entries with reference pages, is the first major win. Being able to tack on specific discussion & comments to an entry is gives it the annotation features.

>> do you just want an easy way to build forms? If the latter, other products might be a better fit.

Currently I expect the form building & support pages to be far from turnkey. The "easy" is only in that theres a few simple examples which can be bulit upon. Those simple examples need to have an approved design factor such as reduced duplication (color var's in ZwikiIssueTracker implementation) and where and how to use ZPT, DTML.)

I am eagerly looking to see how other people bridge ZWiki and other products. CMF/Plone seem to be a bit of an example, except so far I only see cross-searching as the extent of it. Hoping other examples will come out of the woodwork from stuff like a Poll added to a GeneralDiscussion page, to integration wtih an annotation product like the Backtalk flavors, or even a Calander/Sheduler. The note-taking & discussion side of a daily-use zope business tool (Lab manager, ??). At one point I was hoping that a lightweight presentation engine could be embedded, so students could visit the presentations after (during) class and leave questions/comments. But this is ALL benefits of Zope CMF tools, as well. ZWiki is the featherweight class...and I like that starting point, others may not.

>> multiple types/tables per folder, or could you put each in a separate subfolder?

I expect multiple types per folder, but not multiple instances of that type. 1 tracker, 1 faq manager, 1 task manager/road map, 1 status report list, 1 inventory, 1 contact list, 1 set of wiki page documents... Multiple projects go in other wiki's, and in SubWikis when they have enoughof a relationship with the parent wiki to easily share pages. Dept\Project\Tool , etc.

My primary use case is a project portal. Ideally I would like to setup a wiki at home to track all the honey-do's and life journaling. Palm's PIM didn't cut it. (Now integrating with mobile pc's is another issue, which the simplicty of a wiki may benefit, although the replication/synchronization my falter.)

Sorry for such a write-up...I need to broaden my horizons, but sometimes its fun to envision a current tool taken to it's extremes and find realistic boundaries, then consider its merits as a stepping stone.

ouch..thats defenitely first draft material. Can I blame it on that I was writing in a 3 line window? ;-) (no.) Must move on, so not going to fix it now.

DeanGoodmanson, 2002/12/05 15:12 GMT (via web):
My original thoughts were not the TWiki spreadsheet , and their database wrapping methods are interesting, also. I haven't investigated how searching works there. I would rarely want data otuside the search window.

Warning: going to rename this page soon.

Toni Arnold, 2002/12/22 19:15 GMT (via web):
Came up today with a combination of IssueTracker and the NLPI Zope product (some kind interactive fiction IDE for inform). To get an idea what I mean look at the screenshot at

The download at the nlpi folder contains win32 binaries (got no other machine), but the interesting source files are (within the Products directory of NLPIaux?.tar.gz):


These install the default IssueTracker found in the ZWiki distribution automatically in the background when first needed. Of course I would like to use custom categories, but at the moment I don't see exactly how to do that ;-)

DeanGoodmanson, 2002/12/23 01:48 GMT (via web):
Adding Categories

Interesting. To add a category you can change the value of categories in the properties on your Zwiki folder.

FlorianKonnertz, 2003/01/19 23:48 GMT (via web):
Questions to comments above

These ideas sounds really like what i'm primarily interested in, great! :-) I currently experiment with custimized IssueTracker and expect some insights these days. For the moment i'd like to ask a few questions (Hi Dean! And also Bill):

Could you explain further: For each item type a class zwikipage mixin and pagetype would need to be added to the ZWiki filesystem product, along with appropriate Properties and Catalog additions. - A mixin class is a class which inherits from various classes, isn't it? Do we need new classes for each new page type?

What is the status of ZwikiIssueTracker development? Did i get i right that there's a discussion about refactoring and that it's to make notations like issue_categories etc. customizable, so different notations get also rendered colored? What alternatives exist to reach the goal of an powerful ZwikiProjectManagement??

This leads me to the next point: Which ZopeProducts? are related to IssueTracking?, ProjectManagement? etc.? Which one do you know and regard as useful for integration? Are there any? Or stay with ZwikiIssueTracker? I collected all i found on and will try some of them the next days. But as far by now i want to stay with ZwikiIssueTracker, only BillSeitz' comments above stimulated me to do this enquiry.

... I'll continue tomorrow, am too tired now. - Cheers, Florian

DeanGoodmanson, 2003/01/20 00:07 GMT (via web):
What is a mixin?

I'm not sure exactly what a mixin is. As I have seen it it's not quite a sub-class. In cases where I've seen these, the parent class is not necesarily "blind" to the sub-class.

Status of ZwikiIssueTracker development? There are bigger issues for the 1.0 release, as far as I know.

ZwikiandProjectManagement? : That's a tough one. Zwiki for a task tracker is a first step. Inter-team communication (beyond lightweight documentation) is a hard step: Contact and Calendar mgt, is where ZWiki as a PIM is also tested. When should these features be built into ZWiki, or into a seperate Zope product to be integrated with a ZWiki? (Or ZWiki integrated into it, such as Plone, etc.)

FlorianKonnertz, 2003/01/29 20:58 GMT (via web):
Abracadabra Object

Just came across Abracadabra Object - I know it and tested the example of the german howto and i know it's a really interesting thing. I still want to build my new contact database and a literature database with it, but there's a resting gap of understanding... :-/ Do you already have an idea how to use it for the ProjectManagement? (Dean,...)? - Perhaps a few comments would bring me on the right path...


A Vision for Zwiki --N888, Thu, 08 Jul 2004 22:23:48 -0700 reply
Some of this discussion is generating possibilities for directions for Zwiki development, right? Well, I thought I would throw my two cents in, again. I believe the Killer App for all wikis will be for anyone-can-contribute, collaborative news/current events reporting. When you can make it easy for professional/semi-professional journalists to create new versions of a story (a Zwiki HTML page), and the various versions of stories on a topic can be sorted by popularity, the end result will be MUCH more balanced, complete and unbiased than the media is today. If I am going to dream about Zwiki's future, that is what I think about. -nate

A Vision for Zwiki --DeanG, Fri, 09 Jul 2004 06:53:44 -0700 reply
Not sure how this applies. Sounds more like PageRating?.