Hi all,
A few days ago I started a conversation with Kake about one unsatisfying aspect of CGI::Wiki's API: that the object-orientedness is not extended to nodes and other concepts in the system. Returning nodes as hashes exposes the internal elements of your implementation, makes it harder for folks to extend nodes via subclasses, and just feels wrong in today's object-oriented world.
I'd love to see CGI::Wiki::Node as a first class object. Then,
* content(), last_modified(), metadata(), etc. are accessor/mutator methods on CGI::Wiki::Node (zero arguments gets the value, one argument sets the value) * verify_checksum() and delete() are methods on CGI::Wiki::Node * retrieve_node() returns an CGI::Wiki::Node object (or undef if it doesn't exist - it is bad form to assume an empty node, IMO) * list_backlinks(), list_dangling_links(), etc. return a list of CGI::Wiki::Node objects
There are some nice utility classes that can help construct the CGI::Wiki::Node class, like Class::Accessor and Class::DBI.
Obviously for backwards compatibility we'd want to keep both APIs around for a while. Kake suggested that we use an api_version parameter in the constructor:
my $wiki = CGI::Wiki->new( api_version => 2, # 1 is hash-based, 2 is object-based ..., );
What do people think?
Jon
Hi all, I'd be interested in talking to anyone who has thought about using TWiki's formatter and Plugins for use with CGI::Wiki.
Regards, Martin.
-- Martin@Cleaver.org - +1 416 832 7759
On Tue 09 Sep 2003, Martin@Cleaver.org wrote:
I'd be interested in talking to anyone who has thought about using TWiki's formatter and Plugins for use with CGI::Wiki.
Just as a piece of administrivia, the cgi-wiki-dev list is really, really new and doesn't have that many people on it yes. I'll be going over my mail archives today and contacting people who've shown interest in CGI::Wiki in the past, but in the meantime, Martin, you might like to punt a mail to the TWiki dev list asking your question there and pointing people at this list. If that's not going to cause politics and unpleasantness for you, of course.
Kake
On Tue 09 Sep 2003, Jonathan Swartz swartz@pobox.com wrote:
A few days ago I started a conversation with Kake about one unsatisfying aspect of CGI::Wiki's API: that the object-orientedness is not extended to nodes and other concepts in the system.
I do agree with Jonathan here. Nodes are returned as hashes for (mostly bogus) historical reasons. They would make much, much more sense as objects.
Obviously for backwards compatibility we'd want to keep both APIs around for a while.
Another possibility is a grand renaming - Kwiki's having one, so why not us? The CGI::* namespace is not really the right place for something that doesn't even do any CGI, plus the name is confusing to people who expect to install CGI::Wiki and have an instant wiki. Wiki::Toolkit is the thing I have in mind.
CGI::Wiki can stick around for a while, to give people time to migrate to Wiki::Toolkit. It may or may not be worth changing it to be a Wiki::Toolkit wrapper before we finally bury it. An advantage of doing that would be that we'd have its comprehensive test suite available to give Wiki::Toolkit a good working-over (though of course I want Wiki::Toolkit to have its own, equally comprehensive test suite).
Votes? Aye? Nay? Offers of help?
Kake
Another possibility is a grand renaming - Kwiki's having one, so why not us? The CGI::* namespace is not really the right place for something that doesn't even do any CGI, plus the name is confusing to people who expect to install CGI::Wiki and have an instant wiki. Wiki::Toolkit is the thing I have in mind.
CGI::Wiki can stick around for a while, to give people time to migrate to Wiki::Toolkit. It may or may not be worth changing it to be a Wiki::Toolkit wrapper before we finally bury it. An advantage of doing that would be that we'd have its comprehensive test suite available to give Wiki::Toolkit a good working-over (though of course I want Wiki::Toolkit to have its own, equally comprehensive test suite).
Votes? Aye? Nay? Offers of help?
I'm in favor of this - though I have less invested because I'm not yet using CGI::Wiki. :) I'd be willing to help design the new class.
Jon
Kake wrote:
Another possibility is a grand renaming [...] Wiki::Toolkit is the thing I have in mind.
On Wed 10 Sep 2003, Jonathan Swartz swartz@pobox.com wrote:
I'm in favor of this - though I have less invested because I'm not yet using CGI::Wiki. :) I'd be willing to help design the new class.
Having slept on it I still can't see any huge drawbacks to this plan, so let's make it an official one.
I was hoping to have finished patching Tom's CGI::Wiki::Kwiki soon, so we could use an instance of that to flesh out the docs and tests - writing the docs directly in POD on the wiki is the first feature that we'd need to get sorted. So I need to make multiple formatters work.
There are all kinds of other highly shiny things we could make a properly powerful Wiki::Toolkit development wiki do - auto-generate tarballs for people to download, auto-syntax-check the tests, auto-check POD validity, that kind of thing.
I have CGI::Wiki::Kwiki CVS access. If you're interested in working on this (it's basically a wiki application built on CGI::Wiki) then drop me or Tom a line. Extra help would very much hurry things up.
Of course there's nothing to stop anybody making a start on Wiki::Toolkit docs/API and just posting it to the list for people to see. Please don't wait for me to start, just dive in and write something.
Kake
-
Jonathan Swartz -
Kate L Pugh -
Martin＠Cleaver.org