I have just discovered that the wiki-toolkit subversion repository has
become corrupted. I have taken a snapshot of it and will attempt to
recover it in due course; in the meantime, the repository iteslf and
parts of the web site http://www.wiki-toolkit.org/ will remain
inaccessible.
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
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
I've released the first (announced) developer version of
Wiki::Toolkit. It's available from CPAN or
http://www.wiki-toolkit.org/download/Wiki-Toolkit-0.69_02.tar.gz
I've also released Wiki::Toolkit::Formatter::Usemod:
http://www.wiki-toolkit.org/download/Wiki-Toolkit-Formatter-UseMod-0.19.tar…
Other associated modules will be forthcoming, although some of
them may be refactored first.
Help in testing this release would be greatly appreciated. I will
release a testing version of OpenGuides that uses this new module before
too long, but in the meantime independent tests (and tests by others
using CGI::Wiki/Wiki::Toolkit would be most useful. In particular, we
are very interested in the database schema upgrade functionality. At
this stage you should consider this functionality unstable and prone to
change and not suitable for use on production data but success/failure
reports on copies of the database would be most appreciated.
Thanks to Nick for the bulk of the new code included in this release.
Here, for reference, is the full changelog from the last released
version of CGI::Wiki:
0.69_02 27 April 2006
Add missing new file lib/Wiki/Toolkit/Setup/Database.pm to
distribution.
0.69_01 23 April 2006
*** IMPORTANT NOTICE *** This release introduces a new database schema
which should be considered beta in nature at this stage. It is not yet
suitable for deployment on production data and should only be tested
on copies of your production data. If it eats your data, you get to
keep the pieces. Additionally, functionality exposed in this beta
release is subject to change.
Rename to Wiki::Toolkit.
Support for moderation on a per-node basis.
Update to the database schema: added needs_moderation column to
node, and moderated column to content
You will need to run wiki-toolkit-setupdb to upgrade your database
Many more plugin points: pre_write + pre_retrieve (get to change
the data), pre_moderate + post_moderate, pre_rename + post_rena
me,
+ post_delete. See test 150 for examples, and the perldoc of
Wiki::Toolkit::Plugin for a description.
Merge Wiki::Toolkit::Formatter::Multiple:
0.02 15 September 2004
Applied patch from Tom Insam to fix bug with
find_internal_links.
0.01 22 September 2003
Initial release.
0.69 22 February 2006
Update to database schema: added an ID column to node, and changed
the content + metadata tables to FK to the ID field, rather than
the node name. Also added rails like schema_info table, to hold
the current database schema version number
You will need to run cgi-wiki-setupdb to upgrade your database
Cheers,
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)