howdy.
What follows is a question I asked Dominic, he suggested that I forward my question, along with his responses, on to the list.
At the bottom, I list the two changes which would make this a really useful tool for me to use.
Background: I run a hosting service for high-traffic webcomics. Currently goats.com and reallifecomics.com are using my stuff. Short version is that I have a large backend of perl code that I use to make functionality available to them by letting them only have to configure a few variables.
I'm setting something up to allow them to put wikis on their sites just by setting a the base_path they want the wiki to live at. I started implementing a lot of this myself, using Text::Wikiformat and then writing all the storage/insert/update/etc myself, but looking at all the improvements in Wiki::Toolkit I'm wondering if I can use this instead.
The problem is that these wikis need to use one set of tables, based on a central "wiki" table that specifies which nodes belong to which wiki/site.
Specific Question: In your opinion, is Wiki::Toolkit flexible enough that I could use it to enable this?
It's not quite there but this shouldn't be hard to add and would be worthwhile.
My current thought are to create a class that inherits from Wiki::Toolkit to allow me to know which wiki I'm referring to, and then to create my own backend type that would use that information to know which tables to select from.
However, it appears that a lot of the SQL is very intermixed with logic (in Wiki::Toolkit::Store::Database), which means that I would end up cut and pasting a lot of that into the functions I overrode, thus diminishing the returns from using Wiki::Toolkit in the first place.
So I guess my questions are:
- am I completely insane for thinking that this would be useful to
me instead of just rewriting a lot of it?
It sounds like a sane idea to me. It's what Wiki::Toolkit is for, after all :)
- and are their plans, as part of the current rewrite, to abstract
out the SQL calls more from the logic? (I didn't see anything along these lines on the site)
We don't have any particular plans to restructure the code at this stage although once we've settle down from our recent naming and schema overhaul it could be considered. However, Wiki::Toolkit is in itself an abstraction layer and it should be possible for it to be generally useful with the interfaces it gives you. If there are bits missing then we need to add them :)
If I understand you, you just need a way to add an extra wiki name identifier (be that a URL, or short name, or whatever) and then be able to name that in Wiki::Toolkit operations. This should be easy to add to the core I think and would be generally useful to be able to run multiple wikis on a single Wiki::Toolkit table, rather than subclassing. In terms of implementation I think we'd just need to have an optional "wiki_id" parameter to Wiki::Toolkit calls, which used an corresponding database column.
Thoughts?
Dominic.
Here are the two changes I think would need to be made to make this relatively simple: - make it easier for the Wiki::Toolkit tables to be integrated into a larger database by allowing an optional "table prefix" of some kind to be specified. This allows it to use a user-configured namespace for its tables, preventing conflicts with other stuff (such as tables called "content"). Also, it creates one option for allowing multiple wikis within a single database/application/whatever.
- follow Dominic's suggestion to use a wiki_id parameter to know which wiki a node "belongs" to. This would require altering a lot of sql calls, but since (it seems) all the other tables are keyed into the node_id of a node, it should (hopefully) be fairly straightforward. The internal_links table may also need to be altered somehow.
In my case, I would create a wiki table that would identify the site and "base_url" for a wiki, and then use that wiki_id to find nodes.
I'm happy to help make these (or other suggested) changes, but I'm new to the community, so suggestions on how to go about doing that are welcome.
thanks, -Phillip
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