CGI-Wiki-dev

cgi-wiki-dev@earth.li

134 discussions

UseMod formatter, and URL-encoding
by Kake L Pugh 26 Jan '05

26 Jan '05

We found a bug in OpenGuides earlier on, caused by this: This is because the node name parameter is not being properly URL-encoded before the Location: header is printed to STDOUT. This bug slipped in because I forgot that CGI::Wiki::Formatter::UseMod's ->node_name_to_node_param method doesn't actually URL-encode, but expects you to do it yourself after calling the method (this _is_ documented). I think it perhaps should, since what I expect from that method is something I can bung into a URL and it will Just Work. However changing it to do that would break backwards compatibility and could lead to things being doubly-encoded, which would suck. Thoughts? I may punt this to cgi-wiki-dev as well. And here it is. What do people think? Who here is using the UseMod formatter? Kake

1 1

Formatter API change proposal
by Kjetil Kjernsmo 25 Jan '05

25 Jan '05

Hi all! The Formatter API was designed on #openguides and here a few months ago. I just released Apache::AxKit::Provider::File::Formatter to make it easy to use any Formatter formatted file within AxKit, but I bumped into a problem that I would like your input on: All the current Formatters simply return HTML fragments from the format method. That is, the stuff they return is something that you would stick in a body element of a HTML document. That's what you'd want in most cases. In other cases, you can't reasonably expect to get just a fragment, you'll get the whole document, even if you're just interested in a fragment. I'd like to create a Formatter around HTML::Tidy RSN, and while libtidy can format fragments, HTML::Tidy can't yet, AFAIK. For an AxKit Provider, you would usually want to return a document, since, in principle it can be served directly to the user. So, I think we need to do something that distinguishes fragments from entire documents. In the original API, I note the following things: 1) the format method did not define its meaning w.r.t. fragment vs. whole document. 2) To retrieve things like title, one needs to first call the format method to do the hard work, then the title method. I suppose it is a Good Thing for those two points to stay the same. Since we allready have to call additional methods to get things like title, I think the most reasonable way to distinguish between fragment and document is to make two additional methods with those names. format would have to be called first, and is free to return what is most reasonable, for Formatter::HTML::Textile, that would be a fragment, like it is now, and for a HTML::Tidy based Formatter::XHTML::HTML it would be a document. If the user needs to be sure to get a fragment or document, s/he would have to call fragment or document on the object _after_ having called format. How does this sound? Then, we need to define what happens if the object cannot return either a fragment or document. I guess the choices are 1) croak, 2) warn the user that the method is not implemented and return undef, or 3) just return undef. If it just returns undef, this should be noted in the documentation of each Formatter. One should be able to meaningfully implement a something that uses different Formatters without having the code die in a special case. OTOH, one would perhaps want to know about it, so a warning may be in order. But then, the warning may just be an annoyance too, and for those who are surprised by a Formatter returning undef in some cases, well, they should have RTFMed... ;-) I'd love to hear your input on these things. Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kjetil(a)kjernsmo.net webmaster(a)skepsis.no editor(a)learn-orienteering.org Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC

3 16

Formatter API specification, version 0.92
by Kjetil Kjernsmo 25 Jan '05

25 Jan '05

Hi again! OK, the Formatter API specification, version 0.92 in all its g(l)ory: NAME Formatter - The Formatter API specification VERSION 0.92 SYNOPSIS Formatters are Perl Modules conforming to the following specification. Formatters are intended to assist the conversion between different markup syntaxes. INTRODUCTION The basic idea of Formatters is to have a simple and standard way to convert from one format to another. This is a common problem across many applications, and so, a simple API for all applications to use is desireable. Formatters generally operate on strings. Formatters can convert any string from any format to any other format. For example, you have a plain text string, possibly with a bit of syntax, and you want to convert it to HTML. You will simply use the appropriate Formatter module, and call the "format" constructor method on it, with the text string as parameter. You may then call either the "document" or "fragment" method to get HTML returned. DESCRIPTION Module naming convention A Formatter module should be named with the format it is converted to first, then the format it is converted from. For example, the module Formatter::HTML::Textile will convert from the Textile syntax to HTML. Methods "format($string)" This is a constructor method and shall initialize the formatter. As argument it must take a string with the text that one wants converted. This method must return the object as a "bless"ed reference. "document" The "document" method may be called on the object after it has been initialized with the "format" method. It must return a full document. In the case where an underlying helper module has no concept of full document, the method must nevertheless make a best effort to return something that can be regarded a standalone document. "fragment" The "fragment" method may be called on the object after it has been initialized with the "format" method. It shall only return a minimal fragment of the converted text, as little as possible markup shall be added to the fragment. In the case where only a full document is available from an underlying helper module, it should make a best effort to strip down to a minimal fragment. "links" This method should return all links found the input plain text string as an array where each element is a hash, with keys "url" and "title", the former containing the URL, the latter the text of the link. If none can be found, an empty list should be returned. If no title can be found, the title key should have an empty string. "title" This method should return the title of the document or "undef" if none can be found. Inheritance from other modules A Formatter module may inherit methods from other modules. It may inherit all the methods mentioned above if they exist in a suitable parent class, and also other methods, to aid setting syntax-specific parameters. Formatter module implementors are encouraged to contact the API author(s) to discuss methods that should be included in the API. Meaning of fragment vs. document It is to be anticipated that not all formats have a concept of full document and others not a fragment. To save the user the trouble of dealing with an error situation, the Formatter must make a best effort to return both. What is meant by a fragment and a full document varies from format to format, and must be dealt with on a per format basis. In the case where it really doesn't make sense to return either a fragment or document, the Formatter may produce a warning, but must nevertheless return a best effort fragment or document. For HTML, a full document is understood to be a complete valid, HTML document. The largest possible HTML fragment consists of the child elements of the "body" element, excluding "body" itself. For XML, any well-formed XML document can be a full document, and any well-balanced XML region can be a fragment. An XML fragment should not contain a Prolog or Document Type Declaration. AUTHOR Kjetil Kjernsmo, <kjetilk(a)cpan.org> ACKNOWLEDGEMENTS The Formatter API was originally conceived on the openguides channel on irc.perl.org. In particular, Tom Insam was an important architect of the API. EXAMPLES The module Formatter::HTML::Preformatted contains a minimal Formatter by the author of the specification. COPYRIGHT AND LICENSE Copyright (C) 2005 by Kjetil Kjernsmo This specification can be redistributed it and/or modified it under the same terms as Perl itself. The author asks that only modules conformant with the specification uses the Formatter:: namespace. Closing in on something...? (I hope, I really need to move on now... :-( ) Cheers, Kjetil -- Kjetil Kjernsmo Astrophysicist/IT Consultant/Skeptic/Ski-orienteer/Orienteer/Mountaineer kjetil(a)kjernsmo.net webmaster(a)skepsis.no editor(a)learn-orienteering.org Homepage: http://www.kjetil.kjernsmo.net/ OpenPGP KeyID: 6A6A0BBC

1 0

UTF-8, Node names, and recent changes
by Tom Insam 16 Dec '04

16 Dec '04

I found a bug with the CGI::Wiki utf8 support - node names in the recent changes list weren't getting handled as utf-8 properly. This fixes it. tom

2 2

Formatter::Pod and line endings
by Tom Insam 16 Dec '04

16 Dec '04

Whilst re-hosting the Wiki::Toolkit development wiki (it's now at http://movieos.org/wiki-toolkit/) we discovered that CGI::Wiki::Formatter::Pod requires the line-endings of the thing it's formatting to be unix-style. This wasn't a problem till I started pointing Safari at it - you're clearly all firefox users - but would be under 'normal' usage. Rather than fix the formatter, I think it's probably better to ensure that whatever formatter we use is always passed unix line endings. This patch (to CGI::Wiki) does this. Actually, now I think about it, would we prefer a patch that ensures that the node contents as stored in the database always have unix line endings, ie move this match to before the node store operation? tom

3 6

Re: [OpenGuides-Dev] SQLite fails after upgrade
by Dominic Hargreaves 06 Dec '04

06 Dec '04

On Mon, Dec 06, 2004 at 08:58:11AM -0500, IvorW wrote: > As far as I know you should not be using SQLite2.pm as this is older than, and superseded > by SQLite.pm, which is actually SQLite version 3 just to confuse you. CGI::Wiki declares a dependency on DBD::SQLite >= 0.25. Is this wrong? Cheers, Dominic.

2 1

CPAN Upload: K/KA/KAKE/CGI-Wiki-0.62.tar.gz
by Kake L Pugh 26 Nov '04

26 Nov '04

The URL http://the.earth.li/~kake/code/CGI-Wiki-0.62.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KA/KAKE/CGI-Wiki-0.62.tar.gz

1 0

Grand Unified Hackfest
by Earle Martin 23 Nov '04

23 Nov '04

For some time there have been mumblings and/or rumblings of the possibility of lots of people hacking together (hmm, lopht) on CGI::Wiki and OpenGuides in the same place. I offered to host, and it's got to the point where I can make good on that. When's good for you? E. -- Earle Martin http://downlode.org/ http://purl.oclc.org/net/earlemartin/

1 1

The grand rename...
by Martin＠Cleaver.org 26 Oct '04

26 Oct '04

Just wondering when/if the grand rename is gonna occur? from #openguides... (12:06:27) MRJC: given that Kake said that CGI/Wiki.pm doesn't do any actual CGI (12:06:48) MRJC: Wiki::Toolkit was the popular opinion (12:07:09) MRJC: jerakeen? (12:43:42) jerakeen: yo (12:44:09) jerakeen: I was very free last weekend... (12:44:13) MRJC: the grand rename? (12:44:18) MRJC: so was I (12:44:48) MRJC: historical fact: not a lot of use apart from lessons learnt (12:45:37) MRJC: :) (12:51:36) MRJC: so next weekend, you are busy? (13:10:11) jerakeen: basically, short-term, I have no time at all. (13:10:22) jerakeen: long term, I can't plan for because my life is completely stuffed. (13:10:28) jerakeen: this is annoying. (13:10:56) MRJC: well, can you tell us your position, so we can proceed knowing what you want? (13:11:32) MRJC: actually, I have very little knowledge of Cgi::Wiki, so it would be down to Kake et al. (13:11:39) MRJC: to interpret what you say. (13:11:41) jerakeen: yep. i want an oop way of dealing with the wiki and it's nodes. (13:12:08) jerakeen: there are 2 objectives. Rename CGI::Wiki, and make it nice. (13:12:16) jerakeen: They're completely independant, frankly. (13:12:32) MRJC: ok, can we do them separately then? (13:12:39) jerakeen: justin's opinion is that we should leave CGI::Wiki as it is, and Wiki::Toolkit should be a new thing that wraps it and provides an oop interface (13:13:05) jerakeen: this is a very compelling argument, but I'm nervous of it because nowadays I prefer incremental work over rebuilding things (13:13:13) MRJC: sounds sensible. the skin and fillet approach. (13:13:43) jerakeen: but, ok, proposal, we make Wiki::Toolkit quite a thin layer of OOP stuff on top of CGI::Wiki, at least initially. (13:13:56) MRJC: eventually the fillet ends up in Wiki::Toolkit (13:14:20) MRJC: working towards CGI::Wiki becoming the empty shell (13:14:30) jerakeen: then we can do two things simultaneously - we can port all the old CGI::Wiki-using things over to using the new interface, and we can refactor the innards to remove the CGI::Wiki dep. (13:14:35) jerakeen: yep (13:15:03) jerakeen: just make sure you get the API right when you design it. (13:15:29) MRJC: who else do we need to get agreement from on this? Kake, Earle? (13:15:55) jerakeen: make sure Dom is happy too. (13:16:05) jerakeen: Don't know who else. Send mail to cgi-wiki-dev Regards, M. -- Martin(a)Cleaver.org (please don't reply to @gmail)

2 1

Bug in CGI::Wiki::Plugin::Diff
by Dominic Hargreaves 26 Oct '04

26 Oct '04

Hi, Since you use &Algorithm::Diff::sdiff, you need to depend on Algorithm::Diff >= 1.13. Currently you don't depend on Algorithm::Diff at all. Cheers, Dom.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
14
Older →

Jump to page:

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