Hello all,

I've been playing with ideas for Wiki::Toolkit for a while, and occasionally inflicting them on Kake. She suggested sending this to the list, so see below... please be kind :)

Justin

---------- Forwarded message ---------- Date: Mon, 11 Oct 2004 04:58:23 -0700 (PDT) From: Justin Kao justin+earth@dicatek.com To: Kake L Pugh kake@earth.li Subject: Re: Wiki::Toolkit suggestions

On Mon, 11 Oct 2004, Kake L Pugh wrote:

On Thu 07 Oct 2004, justin+earth@dicatek.com wrote:

...

I waved my hands and made up some stuff at: http://the.earth.li/~kake/cgi-bin/wiki-toolkit/wiki.cgi?node=API%20Summary

I'm wondering whether you have any thoughts on it, in particular the stuff above the line (i.e. ::Node and ::Store) -- I feel like what I've outlined may be reasonable, and I've written a flat-file store for playing with.

I don't understand it, sorry. Although this may be because I'm not well and am incapable of thinking straight. Could you explain it a bit more?

I can try. Let me know if it still doesn't make sense, in which case it's likely my fault. :)

In my view, Node is slightly more than just a data structure. It knows what Store object it came from ($node->source) so it can save itself and check whether or not it is the latest version and so on. This seems like an important thing for nodes to do if one is mingling data from two different data stores, for instance. After obtaining a node, it can be fiddled with without knowing where it came from, so one could pass the $node around and that would be enough.

As a side benefit, loading a node's content can be delayed until it is actually asked for, at which time the node can call $self->source->read_content. Assuming that loading the metadata will be relatively efficient and/or necessary for performing searches in the first place, methods like list_nodes should return arrays of nodes.

I renamed retrieve_node and write_node to open_node and save_node to reflect the live-ness of a node object. Also, since a node needs to know it's source, new nodes come from from $store->new_node.

metahash, meta2text, and text2meta are provided as 'official' ways to extract a node's metadata all at once. (E.g., my flat-file store uses meta2text and text2meta.)

Code is attached... Sorry for the lack of Pod, but on the other hand, it should be much easier to understand than Kwiki. :)

On a slightly different topic, I've been thinking about front-end components, and how to make them pluggable and still differentiate between the 'layout' of a web page and the 'logic' in a cgi script. (The CGI::Wiki plugins need explicit work from the cgi script... Kwiki plugins happen automatically but depend on a lot of stuff working in a particular way.)

An idea I had is to have a Wiki::Toolkit::Page object embodying the web presentation of a node just like Wiki::Toolkit::Node embodies the database record of a node. It would be the 'view' of model-view-controller. The web page could be broken up into Wiki::Toolkit::PageItem subclasses (one for the node itself, one for the navigation bar, etc.) I've started writing this, but haven't finished yet...

Justin