[cgi-wiki-dev] Fwd: Re: Wiki::Toolkit database question

[Nick Burch]

On Tue, 16 May 2006, Phillip Karlsson wrote:
> At the bottom, I list the two changes which would make this a really 
> useful tool for me to use.

One low-tech hack I've just thought of:

Store the site a node belongs to as a prefix on the node name (have your 
own write code add it in before calling Wiki Toolkit / write a name 
munging pre_write filter).

When you read nodes out, munge the name again (again, in your code, or a 
post_retrieve plugin).

Finally, have the other retrieval stuff (recent changes, find by metadata 
etc) do some filtering. You could do some of it in your own code, but I'm 
sure we could add an optional parameter or two to help you out. We could 
also probably add a few more plugin points to help.


The internal links stuff would need a bit of jigger-pokery, but I'm 
getting quite close to ripping it out and starting again (or at the very 
least put it all in nice helper functions, rather than strewn randomly 
around the code), so some refactoring of that to support you would be 
welcomed :)



Thinking of your other suggestions:
* Adding in a table prefix would be a large scale change to the codebase.
   It might prove a chance to abstract out quite a bit of the SQL, but
    it'll be a lot of work to implement, and even more to test.
   I'd avoid this option if you can.
* Adding a new table for "associated wiki", linking nodes to that, and
    providing filtering
   Quite a bit less work, but possibly harder to test if you've caught all
    the possible places you need to change.
   Would want to be combined with a few more bits of rationalisation of the
    SQL, and certainly an overhaul of the internal_links code.


My thoughts are that the best for wiki toolkit would be the associated 
wiki table option, but probably the quickest and easiest for you would be 
the node name stuff.

Nick