- CGI-Wiki-dev - earth.li

Re: [OGDev] Using trac and svn for other OpenGuides modules
by Dominic Hargreaves 13 Feb '06

13 Feb '06

On Tue, Nov 29, 2005 at 07:51:51AM -0500, IvorW wrote: > This has set me thinking, that we maybe we should have all the subsidiary modules in subversion also. > > ... ant managed by trac. Why not? > > Can trac operate with multiple subversion repositories at different addresses or does it have to be under one roof (which may be a better idea anyway)? The latter. Perhaps we could have an OpenGuides::* in the openguides trac/repo and CGI::Wiki::* in a new cgi-wiki trac/repo? What's the maintenance status of CGI::Wiki these days? ISTR it's still Kake's but I've not seen any activity on it for a long time. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

2 5

[CGI::Wiki] PDF Output
by HERMIER Christophe 20 Jan '06

20 Jan '06

Hi, I am looking for a a Wiki Program. Being a perl guy, I think CGI::Wiki is quite interesting notably because it is a toolkit (so I can hack it if I want) and not a drop in stuff where you can only change a template or two. But on my checklist I need to be able to produce (nice) PDF files out of the wiki pages. At first, I thought that the "Formatter" classes where the sort of thing to do that but it seems they are concerned with input format rather than ouput format. So, How easy/hard would it be to allow PDF rendering of one or more pages in your opinion ?? And by the way of any other output format (I may need rtf and stuff like that too) Is there any work in that direction ? Regards, Christophe.

4 3

RFC: CGI::Wiki::AutoPlugin
by IvorW 10 Dec '05

10 Dec '05

Not written the code yet, just after some feedback. =head1 NAME CGI::Wiki::AutoPlugin - Automatic marshalling of CGI::Wiki plugins =head1 SYNOPSIS use CGI::Wiki::AutoPlugin; my $ap = CGI::Wiki::AutoPlugin->new( key1 => value1, key2 => value2...); $ap->register( $wiki ); $ap->despatch( 'pre_write'); =head1 DESCRIPTION L<CGI::Wiki::Plugin> provides a basic framework for writing additional modules that work with L<CGI::Wiki> objects. But, the process of using the plugins from a wiki application to date has been a manual one. The purpose of CGI::Wiki::AutoPlugin is to detect, require and instantiate all the plugin modules that have been installed. An instance of every plugin is available for common method despatching. The wiki application uses despatch to provide a set of standard hooks which may or may not be present in a given plugin. =head1 USAGE =head2 new This will look for all the plugins, and instantiate one of each class by calling new. Passed in is an arbitrary list of named parameters (key and value pairs), which are passed to new for each plugin. Returns a CGI::Wiki::AutoPlugin object. =head2 register Takes a CGI::Wiki object as a parameter, and registers all the plugins to the wiki. =head2 despatch Takes a method name and further parameters to be passed in to the plugins. All the plugins which C<can> call the method are called. Any modifiable parameters are passed by reference (e.g. may be objects), hence may be changed by one plugin before another plugin sees them. The following standard hooks are used: =over 4 =item C<pre_retrieve> $ap->despatch( 'pre_retrieve', $node); Called before retrieving a node from the database, A suitable place to check whether the user is permitted to read the node. Also, a place to munge UTF8, word separation (space or underscore) and capitalization. =item C<post_retrieve> $ap->despatch( 'post_retrieve', $node, $content, \%metadata); We've just got a node back from the database. Here we can do any munging needed before we look at the data. =item C<pre_write> $ap->despatch( 'pre_write', $node, $content, \%metadata); Again, a suitable place for an authentication check and/or some munging. =back =head1 SUPPORT Please discuss on the cgi-wiki-dev mailing list: http://www.earth.li/cgi-bin/mailman/listinfo/cgi-wiki-dev =head1 AUTHOR Ivor Williams CPAN ID: IVORW ivorw-openguides(a)xemaps.com http://openguides.org/ =head1 COPYRIGHT This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself. The full text of the license can be found in the LICENSE file included with this module. =head1 SEE ALSO L<CGI::Wiki::Plugin>, L<CGI::Wiki>.

1 0

Re: [OGDev] Re: [OpenGuides-Dev] Release, bugs, and Search::InvertedIndex support?
by Dominic Hargreaves 21 Nov '05

21 Nov '05

On Mon, Nov 21, 2005 at 10:39:19AM -0500, IvorW wrote: > I think it's worth retaining the pluggability of searches, so that we could add alternative(s) to Plucene at some future stage. I had a problem with installing Plucene on one machine, and fell back to SII, but since resolved the problem with Plucene. Noted. > IMHO, it's nice to have an alternative to Plucene so that we can check it for anomalies in the search results, even though it's inferior. > > By the way, any news on the proken compatibility with the latest Text::WikiFormat? I needed to dive into backpan to retrieve an old T::WF that worked with CGI::Wiki. This shouldn't be needed in the latest release. It was fixed in: http://dev.openguides.org/changeset/707 It should probably be caught in CGI::Wiki too, but at the moment at least I don't have any direct involvement in the development of that. Cheers, Dominic. -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

1 0

text::wikiformat error on creation of new wikis.
by Bob Walker 07 Oct '05

07 Oct '05

the error people get when havign done a clean install is Can't call method "type" on an undefined value at /usr/local/lib/perl5/site_perl/5.8.5/Text/WikiFormat.pm line 234 this is caused by the latest version of Text:Wikiformat if you revert back to 0.71 or so it goes away. However up and running sites arnt affected. So when setting up a new CGI:wiki:Kwiki wiki yesterday i got the error. So i manaully enterd the url to get the edit page http://example.com/examplewiki/?node=HomePage;action=edit i then added stuff to the page and commited at which point the error goes away. Therefore i propose the problem lies in the intial Homepage creation code. which possibly explains the failing tests as well. Hopefully this will help actual programmers track down the bug. -- Bob Walker http://www.randomness.org.uk/ Very few things dont taste good once deep fried.

1 0

[cgi-wiki-dev] bug when passing database handle to CGI::Wiki::Store; :MySQL::new ?
by Jeremy Kitchen 05 Sep '05

05 Sep '05

here's a small snippet, I have a database handle that has been created elsewhere (I'm embedding CGI::Wiki into another application for users to self-document how to use the software :) my $store = CGI::Wiki::Store::MySQL->new( dbh => $dbh ); (assuming that I've also created the search and formatter and created a CGI::Wiki object called $wiki): $wiki->write_node($node,$content,$checksum); the error I'm getting is this: [Tue Aug 30 16:31:45 2005] [error] [client 192.168.1.106] Unknown encoding '' at /usr/lib/perl5/site_perl/5.8.5/CGI/Wiki/Store/Database.pm line 1126, referer: http://localhost/cgi-bin/document.dhtml I took a look at Database.pm, line 1126 and it refers to $self->{_charset}... so I looked for where that's set, and it looks like it's being set in the new() method: $self->{_charset} = $args{charset} || "iso-8859-1"; but that's only being called if you're NOT passing a database handle.. I've tried calling new() like so: my $store = CGI::Wiki::Store::MySQL->new(dbh => $dbh, charset => 'iso-8859-1'); but, as expected, that didn't work (since the code didn't look like it was going to set it) is this a bug, or am I doing something wrong somewhere / haven't looked into the code far enough? Thanks! -Jeremy -- Jeremy Kitchen ++ kitchen(a)scriptkitchen.com In the beginning was The Word and The Word was Content-type: text/plain -- The Word of Rod.

2 1

Text::WikiFormat 0.75 causes CGI::Wiki to fail tests
by IvorW 21 Jul '05

21 Jul '05

I've not got to the bottom of this one yet, but 0.75 is a substantial change. It could be the case that: a) A CGI::Wiki or OpenGuides site using the latest T::WF will be broken. b) The failing tests in C::W are harmless I recommend using version 0.72 until this is fixed. I've not yet submitted a bug report to Chromatic, as I have not debugged the failing tests sufficiently to do so. Ivor.

2 1

Administrivia: held postings and spam filtering
by Dominic Hargreaves 30 Jun '05

30 Jun '05

Just a quick note to let you know that due to an unwieldy numbers of spams to the list, I have discarded a large number (> 1000) of posts. It is possible that I have discarded valid posts, for which I apologise. I have now set up a filter to automatically discard anything which spamassassin scores as spam, which should keep things more managable in the future. Cheers, -- Dominic Hargreaves | http://www.larted.org.uk/~dom/ PGP key 5178E2A5 from the.earth.li (keyserver,web,email)

1 0

CGI::Wiki::Plugin::RSS::ModWiki
by Earle Martin 06 Apr '05

06 Apr '05

Hello, (Quiet round these parts.) In responding to a request from Jo Walsh yesterday to add some rdfs:seeAlso properties to the items in the london.openguides.org RSS feed, I took a look at the code of C::W::P::R::MW for the first time and realised it could do with some changing. Namely, the code appears to have been based on part of http://www.usemod.com/cgi-bin/wiki.pl?WikiPatches/XmlRss which in itself is really not the best code it could be. In particular, it uses XML::RSS to do a lot of stuff that could be seamlessly replaced with simple string concatenation, and by relying on XML::RSS's pre-rolled methods to generate things like "<dc:title>Something Or Other</dc:title>" you lose the ability to write your own custom RDF. So, I stripped out anything to do with XML::RSS and replaced it with a bunch of simple strings. I can't prove it, but my instincts tell me the resulting code actually runs a little faster. (Certainly no objects are generated and laden with attributes etcetera.) I've actually put it to run live, and the result can be seen at http://london.openguides.org/?action=rss . A patch is attached to this message for my update. Kake, could you do the honours? I'm not sure if CGI::Wiki provides an RDF option, though - at least, I don't think it does - so you'll need to remove the four lines that match "$rdf_url". This is the complete patch just so you can see what I did. I should probably work out a way to get those lines into OpenGuides::RDF somehow - any suggestions, anyone? I'm not sure how many CGI::Wiki modules (and consequently OpenGuides modules) use any of the XML::* modules, but hopefully this will cut down the dependencies a bit. Cheers, Earle. hopefully this will cut down -- Earle Martin http://downlode.org/ http://purl.oclc.org/net/earlemartin/

2 3

Formatter API Specification and modules
by Kjetil Kjernsmo 28 Jan '05

28 Jan '05

Hi there! There were much talk about the Formatter API, and me and Tom has done it mostly off-list. It is something we both like. I have just uploaded the Formatter API 0.93 to CPAN, along with three related modules, conforming to or using the spec. Formatter::HTML::Preformatted is a very minimal module, just adds PRE elements to the text and finds the URLs. Then there is Formatter::HTML::HTML, which attempts and fails to use HTML::Tidy to clean up the HTML. I don't know why, and have marked it a "developer release" for this reason. Those who feel that this would be really useful and/or grok HTML::Tidy may want to have a look. If all tests pass, then it works for you, it doesn't for me... :-) The last uploaded module is an AxKit Provider that can make use of any Formatter. Cheers, Kjetil (who is feeling much better now)

1 0