I just discovered an interesting project called "Add Your Own":
It's a wiki restaurant review system! They even have a rudimentary metadata
system for locations and restaurant types. Is it worth us plugging the OG
system to them?
One interesting thing their site does that ours doesn't is a summary view:
I think this is a smart innovation. It would be nice to be able to do that
for a given category - see a list of all the nodes, with selected metadata
fields, in a tabular format. Maybe this is something I should have a go at,
since it's long overdue that I contributed some more code.
Ha! Someone's already mentioned us to them! Fantastic.
# Earle Martin http://c2.com/cgi/wiki?EarleMartin
hi, i have just dug out a patch for OpenGuides::RDF i wrote around 6
months ago but stalled on because it had non-cpan dependencies, then i
forgot about it. now it doesn't. but maybe the code there's changed?
it doesnt do much but fixes the problem of there being none of the
category information getting through to the RDF and of everything
being allegedly a chefmoz:Restaurant.
also for rdf reasons i thought it would be nice to have the locale as
a uri, rather than a string, e.g.
http://london.openguides.org/locale#Cockfosters so you can say things
about unambiguously the same thing elsewhere. it wouldnt nesc have to be a
resolving uri though i guess it could really be the uri of the category
page? i'd like to incliude this behaviour in my proposed patch though,
what do you think?
i also noticed what a lovely scutterplan you get if you hit e.g.
are you doing a fair bit of work on this anyway kake?
i am writing a little scutter that would grab an openguides
rdf model and geenrate map formats with it, e.g. for
http://www.mapbureau.com/pointmapper/ . this would be a great service for
the OG pages themselves if we could get free (or even cheap?) base maps.
ah, i can dream. i have most of central oxford drawn on my gps though.
"Common sense won't tell you. We have to tell each other." -DNA
Reflecting on the Longon.OG site, I wonder if it might be desirable to alter node
versions after the event. In particular, the following scenarios:
You posted a minor change but forgot to set the edit_type to "Minor tidying", and it now
appears on the front page.
You notice that a newbie has posted 10+ changes to the same node as
"Normal editing", pushing out any prior changes that were useful or informative.
There are probably others, notably with edit warfare (which, no OpenGuides
site has yet had to deal with and, cross fingers, won't).
I just wonder whether it might be useful to provide a varient of the node_history or
recent_changes page that allows you to change the edit_type of an existing node
Being laid up with the flu, I couldn't sleep last night and my brain was
aflame. So, I did a bit of hacking, and here's the result:
Note the link at the bottom right. Try creating some test nodes and deleting
them! (If you could not delete "Example Node" I'd be grateful. The password
The way this works is that it checks the password you enter against a value
in wiki.conf. Not very subtle. However, this exposes a security issue, that
I believe Ivor first picked up on - by default, wiki.conf is in the same
directory as wiki.cgi, which means that anybody who knows that can just look
and see all the configuration settings, including the password.
So, what's needed is for wiki.conf to be somewhere that's not
world-readable. I was thinking maybe at configure time you'd be asked for a
location for wiki.conf to be stored in, and that value could be stored in a
file next to wiki.cgi for it to read.
 I'll need to modify the config script to ask you for a password next.
hex on irc.perl.orghttp://purl.oclc.org/net/earlemartin/
Checking out a fresh "grubclone" on un, I get the following in ./Build test:
ok 1 - use OpenGuides::CGI;
ok 2 - ->make_prefs_cookie dies if no config object supplied
ok 3 - ...or if config isn't a Config::Tiny
ok 4 - ...but not if it is
ok 5 - ->make_prefs_cookie returns a cookie isa CGI::Cookie
ok 6 - ->get_prefs_from_cookie dies if no config object supplied
ok 7 - ...or if config isn't a Config::Tiny
ok 8 - ...but not if it is
ok 9 - get_prefs_from_cookie can find username
ok 10 - ...and geocache prefs
ok 11 - ...and preview prefs
ok 12 - ...and latlong prefs
not ok 13 - ...and formatting link prefs
# Failed test (t/13_cookies.t at line 46)
# got: undef
# expected: '1'
ok 14 - ...and minor edits prefs
ok 15 - ->get_prefs_from_cookie doesn't die if no cookie set
ok 16 - ...and returns six default values
# Looks like you failed 1 tests of 16.
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 13
Failed 1/16 tests, 93.75% okay
Also, I have applied a change to wiki.cgi, to use CGI::Wiki::Plugin::Diff
instead of OpenGuides::Diff. (but not removed Diff.pm from the dist yet).
t/51_diff.t uses OG::D and uses some stuff with mock objects. Do we
need any tests for diff inside OG, as C::W::P::D has its own tests?
btw, should I have changed the version number to 030_02?
David Cantrell | Reality Engineer, Ministry of Information
If you're doing business with a religious son of a bitch, get it in
writing. His word isn't worth shit, not with the Good Lord telling him
how to fuck you on the deal -- W.S.Burroughs
Attached is a patch to fix a bug in the differences.tt template, whereby
it has the cgi url for the 'List all versions' link hard coded, instead of
using the TT param supplied.
Patch is against 0.30_01 as requested by Kake (although checking, that
file hasn't changed since 0.29 anyway)
knew (at) pimb (dot) org
veeg sent this round the company mailing list today. Very shiny.
Like the alistapart "Taming Lists" article, but much much more. I may
steal one of these tricks to liven up the Reading OpenGuide navbar.
lots of examples of the different ways of applying style to simple html