CGI-Wiki-dev

cgi-wiki-dev@earth.li

134 discussions

CGI-Wiki-Kwiki-0.45 with added diffs, please test
by Ivor Williams 12 Dec '03

12 Dec '03

I have an update to CGI::Wiki::Kwiki to integrate it with my diffing module CGI::Wiki::Plugin::Diff. I attach a tar kit with the full change, including a new template file and updates to CHANGES, MANIFEST, Build.PL etc. I do not have the facilities to run this up as a full wiki site :(. Please can some of you have a go at break^Wtesting it. Just in case mailmangler mangles the tarball, I am including the main body of the change, as a patch to Kwiki.pm: --- CGI-Wiki-Kwiki-0.44/lib/CGI/Wiki/Kwiki.pm Mon Nov 24 20:05:37 2003 +++ CGI-Wiki-Kwiki-0.45/lib/CGI/Wiki/Kwiki.pm Sun Dec 7 12:32:20 2003 @@ -152,9 +152,10 @@ use CGI::Wiki; use Search::InvertedIndex; use CGI::Wiki::Search::SII; +use CGI::Wiki::Plugin::Diff; use Template; -our $VERSION = '0.44'; +our $VERSION = '0.45'; my $default_options = { db_type => 'MySQL', @@ -177,6 +178,8 @@ search_map => "./search_map", }; +our $diff_plugin = CGI::Wiki::Plugin::Diff->new; + sub new { my $class = shift; my $self = bless {}, $class; @@ -246,6 +249,8 @@ search => $self->{search}, ) or die "Can't create CGI::Wiki object"; + $self->{wiki}->register_plugin( plugin => $diff_plugin ); + return $self; } @@ -313,8 +318,14 @@ } else { - if ($args{diffversion}) { - die "diff not implemented yet\n"; + if ($args{diffversion}) { + my %diff = $diff_plugin->differences( + node => $node, + left_version => $args{version}, + right_version => $args{diffversion} ); + + $self->process_template('differences.tt', $node, \%diff); + } else { $self->display_node($node, $args{version}); } ======End of patch========================

4 12

Jody's three patches
by Kate L Pugh 08 Dec '03

08 Dec '03

Thanks for the patches, Jody. As discussed on IRC, the table-prefix stuff does need a little more testing before it goes in. I'm also concerned about quadrupling the test run time... So to confirm, the plan is that you will send me the other two patches made against 0.50_02 and I'll do my best to get them in this weekend. Kake

2 1

::Database::node_exists
by Jody Belka 04 Dec '03

04 Dec '03

Whilst i was working on the previous patch i posted, i noticed that the node_exists routine doesn't do exactly as documented. The documentation states that it returns true if the node has ever been created, and false otherwise. Now, strictly speaking this is correct, but the truth value is actually the version number of the node. Also, it's retrieving the entire node, including metadata, to do this. Now (in some formatters), this method is called for every internal link on a node to determine how to show the link, so it is in the best interest to do the minimum necessary. Therefore, what i suggest (after having talked it over with Earle), is to seperate node_exists into two seperate methods, one called node_exists that only does this check, and nothing more, and another called node_version, that is actually documented as returning the version number. I have included two patches along these lines. One of them (CGI-Wiki-node_exists.diff) is against 0.50_01. The other is against my local dev-tree, which so far consists only of this patch and the earlier two. Included along with the new method is a new test file that makes sure it is working properly. Thankfully, unlike the table-prefix changes, this does not add a very significant amount of time to the test run ;) -- Jody Belka knew (at) pimb (dot) org Modules/Diffs @ perl.pimb.org/modules

1 0

C::W::Store::* diff
by Jody Belka 04 Dec '03

04 Dec '03

This is a diff against CGI::Wiki::Store::* that splits out the SQL portions of some more of the methods in ::Database, and renames the one existing sql-method that was there. The purpose of this patch is to make changing some of the sql in descendents possible without having to copy in the appropriate routine. I haven't changed all of the methods, as some of them don't seem to make much sense split out. This came about as support for some other code I was writing, which does some inheritence from various parts of CGI::Wiki and needed some changes to the SQL statements. I'll post more about this at a later date. *** Important Note ***: This diff is not made against current code, but against the previous diff I posted to the list, which was against 0.50_01. At the point i'm sending this mail, the previous one has not appeared yet, so I will also mention that both diffs can be found at http://perl.pimb.org/modules/ -- Jody Belka knew (at) pimb (dot) org

1 0

updated table-prefix diff against 0.50_01
by Jody Belka 04 Dec '03

04 Dec '03

Enclosed is the updated version of my table-prefix diff, which includes changes to the db setup scripts unlike the previous version. I promised this to Kake a while back now, but only just got round to doing it, sorry. -- Jody knew (at) pimb (dot) org

1 0

Search indexer errors
by Kate L Pugh 28 Nov '03

28 Nov '03

Earle Martin <openguides(a)downlode.org> wrote to openguides-dev: > [Thu Nov 27 23:15:03 2003] index.cgi: > Search::InvertedIndex::remove_index_from_group() - Corrupted database. > Unable to find 'ged_000000000000_c_000000000523' record > [Thu Nov 27 23:15:03 2003] index.cgi: at > /home/earle/openguides.org/lib/CGI/Wiki/Search/SII.pm line 204 > > This is for the London site. Should I be worried? It's deja-vu all over again: http://openguides.org/mail/openguides-dev/2003-September/000039.html Search::InvertedIndex does throw these little errors from time to time. Like, about three times a year, which makes it very difficult to track down. So what can we do about it? CGI::Wiki only has two search backends so far. One is the Search::InvertedIndex one, and the other is based on DBIx::FullTextSearch, which only works on MySQL. There really is a dearth of decent indexing/searching modules on CPAN. Does anyone know of any that I've overlooked? Simon Cozens is working on Plucene, a port of Lucene to Perl: http://blog.simon-cozens.org/bryar.cgi/id_6587 I've not properly looked into Lucene though, since it's written in Java and I only found out about Plucene last night. Anyone here used it? Another option would be rewriting Search::InvertedIndex to be simpler and hence hopefully less likely to go wrong. I did a fair bit of work towards this about a year or so ago, and sent a multitude of patches to the author, but he is very busy and apologised profusely for not having time to integrate them. I am not hopeful that they will ever go into the distribution, but they might be useful for a simple rewrite that could be released as Search::SimpleIndexer or Search::InvertedIndec::Simple or something. I don't want to tread on the guy's toes, and I don't even think he would see it that way, especially as CGI::Wiki simply doesn't need much of the complexity that's in the current distro. The drawback of that approach (ie me writing a new search module) is that I am already overwhelmed with programming tasks. I am deep in the guts of both CGI::Wiki and OpenGuides this week, and I don't want to start a major new project until the current work on those two projects is released. I *may* be able to break the back of the current stuff this weekend. Is anyone else interested in a Search::InvertedIndex rewrite? You could write code, docs, tests or all three. Kake

1 0

New feature for UseMod formatter
by Kate L Pugh 24 Nov '03

24 Nov '03

I set up a wiki here at work but was berated for breaking our branding. We are http://state51.co.uk/ and there is definitely no capital "s" allowed. Now, CGI::Wiki::Formatter::UseMod forces node names in links to be ucfirst, to avoid ending up with six home nodes called things like "home", "Home", "HOME", etc. Consistency is a good thing. You can turn this munging off entirely, but you can't *partly* turn it off. I added an option to let you do some last-minute munging of the node names, but I'm not sure I got the name right. It's currently called "munge_node_name" and its documentation is below. Comments ASAP please - I'd like to upload this as soon as PAUSE comes back. Kake METHODS new my $formatter = CGI::Wiki::Formatter::UseMod->new( extended_links => 0, # $FreeLinks implicit_links => 1, # $WikiLinks force_ucfirst_nodes => 1, # $FreeUpper use_headings => 1, # $UseHeadings allowed_tags => [qw(b i)], #defaults to none macros => {}, node_prefix => 'wiki.pl?', node_suffix => '', edit_prefix => 'wiki.pl?action=edit;id=', edit_suffix => '', munge_urls => 0, ); Parameters will default to the values shown above (apart from "allowed_tags", which defaults to allowing no tags). Internal links "node_prefix", "node_suffix", "edit_prefix" and "edit_suffix" allow you to control the URLs gener- ated for links to other wiki pages. So for exam- ple with the defaults given above, a link to the Home node will have the URL "wiki.pl?Home" and a link to the edit form for the Home node will have the URL "wiki.pl?action=edit;id=Home" (Note that of course the URLs that you wish to have generated will depend on how your wiki appli- cation processes its CGI parameters - you can't just put random stuff in there and hope it works!) Internal links - advanced options If you wish to have greater control over the links, you may use the "munge_node_name" parame- ter. The value of this should be a subroutine reference. This sub will be called on each inter- nal link after all other formatting and munging except URL escaping has been applied. It will be passed the node name as its first parameter and should return a node name. Note that this will affect the URLs of internal links, but not the link text. Example: # The formatter munges links so node names are ucfirst. # Ensure 'state51' always appears in lower case in node names. munge_node_name => sub { my $node_name = shift; $node_name =~ s/State51/state51/g; return $node_name; } Note: This is advanced usage and you should only do it if you really know what you're doing. Con- sider in particular whether and how your munged nodes are going to be treated by "retrieve_node".

2 2

0.50_01 release candidate
by Kate L Pugh 20 Nov '03

20 Nov '03

Since Jody was waiting for me to finish reworking the tests, I hurried up and got it finished last night. Didn't release it though, and now PAUSE seems to be inaccessible, bah. The *only* changes in this release are tests and documentation. I would really appreciate it if as many people here as possible could run the test suite of 0.50_01 and report any failures. You can get it from here: http://the.earth.li/~kake/code/CGI-Wiki-0.50_01.tar.gz Kake

1 0

RE: [cgi-wiki-dev] SQLite Backend
by Naved, Masroor 18 Nov '03

18 Nov '03

> -----Original Message----- > From: Kate L Pugh [mailto:kake@earth.li] > Sent: Friday, November 07, 2003 11:02 AM > To: cgi-wiki-dev(a)earth.li > Subject: Re: [cgi-wiki-dev] SQLite Backend > > > > Blimey. ->write_node should not fail silently. The perldoc says: > > Returns 1 on success, 0 on conflict, croaks on error. > > If it's not doing that for you then that's a bug. Can you > send me either as small a test case as possible or failing > that all your code. My mistake, I was not checking the returned value from write_node. I thought it would throw an error in the Apache error log. > I am wondering if it should do so. It'd mean an extra > preliminary database call (to check table existence) every > time you tried to write a node, which would increase load. > Also if you typoed the database name you wouldn't be hitting > the database you expected - which would be a right pain in > the case of SQLite since it'd just create you a new database > file and then you'd be wondering where all your data went. > > Opinions on that please. After looking around I found CGI::Wiki::Setup::SQLite module. Because of my newness with Perl and the CPAN I thought all needed modules and/or related modules would be listed in the webpage of CGI::Wiki at the cpan site, after finding the setup functions, it was smooth sailing. :) > > The pointer to cgi-wiki-createdb is in INSTALL :) Should it > be more prominent, or did you just forget to read that file? > There's a *lot* of info in there. Maybe it should be in > README too - would that have helped? I used the command 'perl -MCPAN -e shell' to start a CPAN prompt and just did a 'install CGI::Wiki'; I never knew that there was a INSTALL doc to look at. I thought that the document on the www.cpan.org site was the INSTALL/README file, I guess I was wrong about that. > Oh, relating to this, Tom - do you want to take out the > 'dbuser' requirement in CGI::Wiki::Kwiki and make a new > release? I keep having to put dbuser => "thisisnotused" and > it's bugging me :) I tried this after finding the CGI::Wiki::Setup::SQLite module, just in case. It worked okay, I use the command without entering a username or password, just a file path. Thanks for the info and help. -Masroor

2 1

Table-prefix support
by Jody Belka 18 Nov '03

18 Nov '03

I've just hacked table-prefix support into my local copy of CGI::Wiki so as to enable all the OpenGuides sites hosted on my system to work out of one central database. Is this something other people would be interested in, and should i sort out some patch files with the changes i made and then email them to the list? Jody knew (at) pimb (dot) org

2 2

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

CGI-Wiki-dev