CGI-Wiki-dev October 2004

cgi-wiki-dev@earth.li

8 participants
10 discussions

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

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

Creating URLs
by Tom Insam 26 Oct '04

26 Oct '04

I need a canonical, wiki-wide way of turning a node name into an URL. Right now, in CGI::Wiki::Kwiki, the formatter does it one way, the 'list all pages' page does it another way, and the 'converting back from passed url to node name' code lives in yet a third place. This is totally crazy. The formatter modules all need a way of turning a node name into an url for embedding in <a> tags. The wiki code itself will need to turn node names into urls for linking from various other places. I'd like my Node object to know what their own urls are. And preferably I'd like the code that turns a name into an url to live in the same source file as the code that takes a passed CGI request parameter and turns it into a node name. Thus it seems to make sense to put this code into CGI/Wiki.pm itself. This will, alas, entail great change on the part of the formatters. Specifically, we'll have to no longer pass node-prefix, etc, to the formatters, but instead have them call back to CGI::Wiki when they need a link for a node. Is this going to be possible? The alternative is to have the formatters provide a 'linkify this node name' method, which is much less elegant, but much simpler. Both methods will require new releases of all formatter modules. I prefer the first one, naturally, because it's more elegant, but it will break existing code, whereas merely adding a method will let legacy stuff keep going. Do people have opinions, thoughts, etc? tom

4 6

Re: Wiki::Toolkit suggestions (fwd)
by Justin Kao 15 Oct '04

15 Oct '04

Hello all, I've been playing with ideas for Wiki::Toolkit for a while, and occasionally inflicting them on Kake. She suggested sending this to the list, so see below... please be kind :) Justin ---------- Forwarded message ---------- Date: Mon, 11 Oct 2004 04:58:23 -0700 (PDT) From: Justin Kao <justin+earth(a)dicatek.com> To: Kake L Pugh <kake(a)earth.li> Subject: Re: Wiki::Toolkit suggestions On Mon, 11 Oct 2004, Kake L Pugh wrote: > On Thu 07 Oct 2004, justin+earth(a)dicatek.com wrote: > > I waved my hands and made up some stuff at: > > http://the.earth.li/~kake/cgi-bin/wiki-toolkit/wiki.cgi?node=API%20Summary > > > > I'm wondering whether you have any thoughts on it, in particular the stuff > > above the line (i.e. ::Node and ::Store) -- I feel like what I've outlined > > may be reasonable, and I've written a flat-file store for playing with. > > I don't understand it, sorry. Although this may be because I'm not > well and am incapable of thinking straight. Could you explain it a bit more? I can try. Let me know if it still doesn't make sense, in which case it's likely my fault. :) In my view, Node is slightly more than just a data structure. It knows what Store object it came from ($node->source) so it can save itself and check whether or not it is the latest version and so on. This seems like an important thing for nodes to do if one is mingling data from two different data stores, for instance. After obtaining a node, it can be fiddled with without knowing where it came from, so one could pass the $node around and that would be enough. As a side benefit, loading a node's content can be delayed until it is actually asked for, at which time the node can call $self->source->read_content. Assuming that loading the metadata will be relatively efficient and/or necessary for performing searches in the first place, methods like list_nodes should return arrays of nodes. I renamed retrieve_node and write_node to open_node and save_node to reflect the live-ness of a node object. Also, since a node needs to know it's source, new nodes come from from $store->new_node. metahash, meta2text, and text2meta are provided as 'official' ways to extract a node's metadata all at once. (E.g., my flat-file store uses meta2text and text2meta.) Code is attached... Sorry for the lack of Pod, but on the other hand, it should be much easier to understand than Kwiki. :) On a slightly different topic, I've been thinking about front-end components, and how to make them pluggable and still differentiate between the 'layout' of a web page and the 'logic' in a cgi script. (The CGI::Wiki plugins need explicit work from the cgi script... Kwiki plugins happen automatically but depend on a lot of stuff working in a particular way.) An idea I had is to have a Wiki::Toolkit::Page object embodying the web presentation of a node just like Wiki::Toolkit::Node embodies the database record of a node. It would be the 'view' of model-view-controller. The web page could be broken up into Wiki::Toolkit::PageItem subclasses (one for the node itself, one for the navigation bar, etc.) I've started writing this, but haven't finished yet... Justin

2 1

RFC: OpenGuides/CGI::Wiki (Wiki::Toolkit!) Hackfest
by Earle Martin 11 Oct '04

11 Oct '04

The idea of a hackfest was mooted at the recent London.pm social. Topics for the session: - Munging CGI::Wiki into Wiki::Toolkit. - General OpenGuides hackery. The venue would be my place, unless someone has an objection - bandwidth in both wireless and wired varieties is available. We would get food (pizza?). Date - probably a Sunday. Some time soon. Who's up for it? -- Earle Martin http://downlode.org/ http://purl.oclc.org/net/earlemartin/

2 1

Re: [OpenGuides-Dev] sqlite performance and migration?
by Dominic Hargreaves 06 Oct '04

06 Oct '04

On Wed, Oct 06, 2004 at 12:48:57PM +0100, David Cantrell wrote: > I'd define the tables in the new db but without foreign key constraints > or indices; > then for each table, select all the rows from the sqlite db and insert > into the new one; > finally, turn the constraints and indices on > > The usual caveats about SQL dialects and portability apply, of course. It would be really excellent if someone could write a set of scripts for doing this for CGI::Wiki databases and this script could be included in CGI::Wiki. Cheers, Dominic.

1 0

Formatters reorg
by Kake L Pugh 04 Oct '04

04 Oct '04

This is long, but I think worth reading. I had this mail from a chap called Kjetil Kjernsmo (who is now on this list): > I'm developing a system I call TABOO, a little something based on > AxKit. I've got a small demo on http://demo.kjernsmo.net/ Please feel > free to play with anything. You can log in as foo or bar with password > trustno1 :-) bar is an editor. > > Currently, I'm working on the problem you've been addressing with your > CGI::Wiki::Formatter::* People will submit things to the site, either > as stories or as comments (and in the future, longer articles). Most > user will not know HTML, and they are probably unwilling to learn any > markup language, allthough some may do things like putting some > *asterikses* here and there... > > I think you have something good going with the CGI::Wiki::Formatter::* > classes there, and I wouldn't want to reinvent your wheel. I wouldn't > want to have a lot of dependencies, but I see you're not actually > use-ing CGI::Wiki in those, and package them separately, which looks great! > > So, before I go around hacking on it, I figured I'd ask you if you > think that it would be straightforward to integrate > CGI::Wiki::Formatter:: modules outside of CGI::Wiki? and I replied: > On Sat 25 Sep 2004, Kjetil Kjernsmo <kjetil(a)kjernsmo.net> wrote: >> So, before I go around hacking on it, I figured I'd ask you if you >> think that it would be straightforward to integrate >> CGI::Wiki::Formatter:: modules outside of CGI::Wiki? > > It's perfectly possible. I used CGI::Wiki::Formatter::UseMod in a > half-assed bulletin board thing I wrote for work. Just instantiate > the formatter and call ->format > [...] > I'd be happy to give you a hand with your formatter. Maybe this might > be a nice way to start moving CGI::Wiki things to the Wiki::* space. > I'd really like CGI::Wiki::Formatter::UseMod to be called something > like Wiki::Formatter::UseMod, so you might want to be thinking about > using that namespace. > > In terms of how to get started, I'm unsure that Text::WikiFormat is > the best route any more, since I've been hitting its limitations and > chromatic is far too busy to do much with it. I quite liked the > original (ie pre-obscure code) Kwiki approach of having little methods > to handle each bit of markup. Then there was lots of discussion on #OpenGuides. IRC log with some stuff cut out follows - I don't think I cut out anything important. I did cut out some suggestions where the suggester later decided it was a bad idea, just because there was so much of it. 21:40 <KjetilK> basically, I have written a Wiki::Formatter::Textile, but instead of using it with CGI::Wiki 21:40 <KjetilK> I'm using it with my TABOO project... 21:40 <KjetilK> which is something I build on the top of AxKit 21:51 <jerakeen> ooooh, I was going to write W::F::T. 21:51 <jerakeen> how are you doing page linking? 21:52 <KjetilK> I'm just calling Text::Textile to do the hard work, and it does that, apparently 21:53 <KjetilK> I'm don't want to upload it to CPAN before I have talked with the rest of the interested folks, but I'll put it up on a my webserver in a minute, you can have a look 21:53 <KjetilK> (it is very simple, really...) 21:53 <jerakeen> for the backlinking tracking, etc, CGI::Wiki likes to ask for a list of other wiki pages you're linking to. You are returning an emtpry list? 21:54 <KjetilK> http://dev.kjernsmo.net/tmp/Wiki-Formatter-Textile-0.01.tar.gz 21:55 <KjetilK> no, that's one of the things I didn't know that I suspect I should learn about... :-) 21:55 <KjetilK> is that only internal links or also external links? 21:56 <jerakeen> internal links only. 21:56 <jerakeen> see the find_internal_links method in http://search.cpan.org/src/KAKE/CGI-Wiki-0.59/lib/CGI/Wiki/Formatter/Defa ult.pm 21:59 <jerakeen> linking, though - normall wikis use a different linking style to link to internal pages than to link to external ones 22:03 <jerakeen> you could subclass T::T instead of merely calling it, and override the format_link method.. 22:04 <jerakeen> it's more that you don't want to express internal wiki links as http://site/wiki.cgi?node=Whatever 22:04 <jerakeen> the wiki should be generating the links itself, so you can move the site and it remains internally consistent. 22:04 <jerakeen> so maybe something like "this":WikiPage 22:04 <jerakeen> of course, that stuffs the url discovery regexp. 22:05 <jerakeen> and you can't have spaces in page names. 22:05 <jerakeen> I'd be tempted to use the [[Old Style]] links op _top_ of normal textile markup 22:05 <jerakeen> feels slighlty ugly 22:05 <KjetilK> another thing is that I would hope to make it independent of wikis 22:06 <jerakeen> there's not a lot of space to be in that's bigger than Text::Textile and smaller than a wiki formatter. 22:06 <KjetilK> my site isn't a wiki in the "editable by anyone" sense 22:08 <jerakeen> what do you want to do over T::T? 22:08 <KjetilK> not much, really 22:09 <KjetilK> basically, the main idea is to be able to use any formatters CGI::Wiki people can come up with... 22:09 <KjetilK> but Textile seems to be nice default for submitted stories... 22:10 <jerakeen> the underlying problem is that there are plenty of plain text => html formatting modules, and none of them have the same api as any other one. 22:10 <jerakeen> so you want to use the CGI::Wiki::Formatter::* namespace as an api 22:10 <KjetilK> exactly! 22:11 <jerakeen> hmm, this feels like a very good thing to do, but the approach is wrong. I'd rather see a formatter module compatibility layer, and a CGI::Wiki::Formatter module that will use any of the compatible formatters. 22:12 <jerakeen> KjetilK: I suggest you make up a vaguely sensible api, then mail the owners of all the text formatting modules complaining until they implement it. 22:12 <jerakeen> the ability to get a list of outgoing links should be in this api. 22:12 <KjetilK> I guess it is why Kake suggested we move into Wiki:: namespace 22:13 <jerakeen> KjetilK: but it's not a wiki feature, it's a really useful real world feature I'd _love_ to see. 22:13 <KjetilK> yep 22:13 <perigrin> same here. 22:14 <jerakeen> alternatively, lets pick a nice namespace we can automatically traverse with Module::Pluggable, say Text::Formatter::* or something, and write lots of compatibility layers in that namespace, so you can programmatically discover formatters. 22:14 <KjetilK> sounds nice 22:15 <KjetilK> how easy is it to get a lot of module owners to support a common API? 22:15 <jerakeen> if you explicitly restrict yourself to 'pretty plain text' -> html modules, you still have quite a few, and that's probably the most useful sort of formatter anyway. 22:15 <jerakeen> KjetilK: T::T will be easy. What other ones are you looking at? 22:15 <KjetilK> POD, usual wiki formatting... 22:16 <KjetilK> BBcode, but I looked at it, and I don't think I can be bothered... :-) 22:16 <KjetilK> HTML::Tidy->clean... 22:16 <jerakeen> I think modules in a dedicated traversible namespace is probably the way to go, the more I think about it, I'd really like the ability to programmatically discover these things. 22:18 <KjetilK> BTW, I think we wouldn't want to constrain ourselves to HTML, FOAF for example might need some of this stuff... 22:19 <KjetilK> eh, not only text->html but also text->rdf (FOAF == Friend of a Friend, a RDF vocab) 22:19 <jerakeen> you're becoming dangerously generalized. text->html is a nice niche that I need about once a week. FOAF I never touch. 22:19 <jerakeen> rdf is also somewhat specialist, and doesn't need a lot of different text-based source formats. 22:20 <perigrin> Kjetilk: solve the first problem ... and if you find you still need/want the second you have half of it's solution there. 22:20 <KjetilK> ok 22:21 <perigrin> it's easier to go from a working text->html to text->[xml|rdf] than it is from text->[something unspecific] 22:21 <KjetilK> I guess CGI::Wiki::Formatter::Default is a good start for an API...? 22:21 <jerakeen> the simplest possible API is a known method name for 'here's text. give me html' 22:22 <jerakeen> assume we'll require an oo model, for the sake of modules that like that. 22:22 <jerakeen> because we're a wiki, we need link tracking, so let's add that as a requirement. 22:23 <jerakeen> we need a namespace. I can't find anything I really like. 22:23 <perigrin> Text::Formatter::* is nice and descriptive. 22:23 <jerakeen> perigrin: I worry about being too vague. I'd like 'html' in there somewhere. 22:24 <KjetilK> if we're talking HTML, we're pretty much tied to the web so, how about 22:24 <KjetilK> WWW::Formatter 22:24 <KjetilK> WWW::TextFormatter 22:24 <KjetilK> WWW::Text::Formatter 22:24 <jerakeen> HTML::Formatter 22:24 <jerakeen> WWW is evil 22:25 <jerakeen> KjetilK: personal opinion leaking there a little... 22:26 <perigrin> WWW tends to be consumers of ... not producers of ... web content too. 22:26 <KjetilK> but if we're talking XHTML:... 22:26 <jerakeen> perigrin: Aaah, much more rational reason 22:26 <perigrin> I live to justify. 22:26 <KjetilK> ok, peri, you're right (as usual) 22:27 # KjetilK doesn't really like to tie it too tightly to HTML... 22:27 <jerakeen> KjetilK: the problem with not, is that you don't really have a use for a non-html target right now. 22:28 <perigrin> KjetilK, later when you generalize you can have XML::Formatter 22:28 <jerakeen> and without a concrete use, you can't come up with a list of things that you want. 22:28 <jerakeen> I can write HTML::Formatter::Textile in about 30 seconds, as soon as we agree on method names. 22:29 <KjetilK> yeah, but the reason why it took me so long to discover the good things that is in C:W:F:* is that it began with CGI and I'm not interested in CGI... 22:29 <knewt> how about Formatter::Textile::HTML, or Formatter::HTML::Textile ? 22:29 <jerakeen> scary top-level namespace.. 22:30 <jerakeen> but very tempting 22:30 <jerakeen> specifically, Formatter::HMTL::Textile 22:30 <KjetilK> Perhaps Text::Formatter: is good... 22:30 <jerakeen> or more generally, Formatter::<to>::<from> 22:30 <perigrin> hrm ... rpn namespaces ... what a concept. 22:31 <jerakeen> perigrin: it's a practical thing. Most of the time, you care much more about what you want than what you have. 22:31 <jerakeen> perigrin: 'reverse polish notation'. fule. 22:34 <KjetilK> hm... isn't <from>::<to> better...? 22:34 <perigrin> No, because you want the thing you change most often on the end. 22:35 <jerakeen> and it's way easier to search for modules given a prefix 22:35 <jerakeen> getting Formatter::HTML::* is easier than Formatter::*::HTML 22:35 <jerakeen> getting Formatter::HTML::* is easier than Formatter::*::HTML 22:35 <KjetilK> ok 22:35 <perigrin> method names 22:35 <jerakeen> see Module::Pluggable 22:35 <KjetilK> how about convert() 22:36 <KjetilK> to do the actuall conversion? 22:36 <jerakeen> format? We are Formatter. 22:36 <KjetilK> yeah, but you do convert something? 22:36 <perigrin> No, you format it. 22:37 <jerakeen> personally I'd also like some methods like title() in there as well. 22:37 <jerakeen> I suggest ->new to get a new object, then ->format($text) to return a lump of HTML 22:37 <perigrin> format in this usage is a synonym for convert 22:38 <jerakeen> also format_file($filename). :-) 22:38 <jerakeen> then, after a formal, methods like title() should work. 22:38 <knewt> general formatting options supplied to new, possibly overridable at the format call? ->format($text [,$options]) 22:38 <jerakeen> and links() 22:38 <KjetilK> ok, I tried to envision having a Convert:: namespace and decided it didn't make sense... :-) 22:39 <jerakeen> knewt: tricky, options hare to make portable. 22:39 <jerakeen> hare/hard 22:40 <knewt> jerakeen: have ->title and such in the original class (eg, Formatter::HTML::Textile), or return a new class from ->format that has the converted stuff in it? 22:40 <jerakeen> knewt: format() returns formatted text. keep the simple bit of the API simple. 22:40 <jerakeen> but it changes the state of the object so that the title(), etc, methods will work. 22:44 <jerakeen> I would say $html = Class->new( $text )->format should work, and $html = Class->new->format($text) should work, and both should do the same thing 22:49 <jerakeen> current Text::Textile API: use Text::Textile qw( textile ); print textile($string); 22:50 <jerakeen> maximum complication of new API: use Formatter::HTML::Class; print Formatter::HTML::Class->format($text); 22:50 <jerakeen> in it's simplest form, we're just turning text into html. it's really, really, simple. 22:50 <knewt> yes, that looks nice 22:50 # KjetilK nods 22:51 <jerakeen> complicated things should also be possible, but don't make the simple api need chained method or scalar references or anything nasty like that. 22:52 <jerakeen> perigrin: Rather than have Text::Carrots and Formatter::HTML::Carrots be a thin wrappre for it, I'd just write Formatter::HTML::Carrots and not write Text::Carrots at all. 22:54 <KjetilK> also, it would be nice if Formatter.pm could say something like "you don't have a formatter for this", if that is the case... 22:54 <jerakeen> knewt: actually, tempting is Formatter->new($text)->from("Textile")->to("HTML"); 22:55 <jerakeen> and Formatter::HTML->new($text)->from("Textile")->format 22:55 <jerakeen> or Formatter::HTML->new()->from("Textile")->format($text) 22:55 <jerakeen> but this is all Phase 2. :-) 22:55 <knewt> not Formatter->from("Textile")->to("HTML")->format($text) ? 22:56 <jerakeen> knewt: put a new() in there, and yep, I like that too. 22:56 <jerakeen> can we decide on the phase 1 api now? I need to go to sleep soon. :-) 22:57 <perigrin> so ... new() and format() 22:57 <KjetilK> right! 22:57 <KjetilK> what does title() do? 22:57 <jerakeen> and links(), at least 22:57 <jerakeen> anyone not like title() 22:57 <jerakeen> ? 22:58 <perigrin> well ... fragments that don't have a title() 22:58 <KjetilK> I didn't get what it was supposed to do? 22:58 <jerakeen> ..can return "". 22:58 <perigrin> also is title() equivalent to the html <title> or <h1> 22:58 <jerakeen> KjetilK: if I format pod for, say, Text::Textile, to HTML, I'd like title to return "Text::Textile". 22:58 <knewt> jerakeen: i think undef, to distinguish from something that actually has a title, but it's empty 22:58 <jerakeen> knewt: good call. 23:00 <KjetilK> uhm, POD, T::T, HTML... 23:01 <jerakeen> aah, sorry, bad module name as an example. :-) 23:02 <KjetilK> OK, I'll rewrite Wiki::Formatter::Textile to the new API! :-) 23:03 <jerakeen> https://dev.jerakeen.org/svn/tomi/Projects/Formatter-HTML-Textile/lib/For matter/HTML/Textile.pm 23:04 <jerakeen> now it has a title method. 23:11 <jerakeen> https://dev.jerakeen.org/svn/tomi/Projects/Formatter-HTML-HTML # 2 down. :-) 23:14 <knewt> how about Formatter::XHTML::HTML - might actually be useful 23:14 <jerakeen> ow, now _there's_ a hard problem. 23:14 <jerakeen> would be really handy, though. 23:14 <perigrin> HTML::HTML should automatically tidy the html though. 23:15 <jerakeen> ooh! ooh! chained formatters! If you can go from Textile->HTML, and HTML->say... .png or something, then Formatter->from("Textile")->to("png") should magically do the Right Thing!!!!! 23:15 <knewt> oooh, that'd be cool 23:15 <jerakeen> probably possible, too. 23:15 <jerakeen> certainly from Textile to XHTML would be useful. 23:16 # KjetilK is working on HTML::Tidy... 23:16 <KjetilK> er, F::H:T 23:16 # perigrin ponders Formatter::PNG::HTML 23:16 <knewt> have to figure out how to resolve multiple same-length paths 23:16 <jerakeen> I'll do POD tomorrow, I think. 23:16 <jerakeen> KjetilK: from Tidy? Doesn't make much sense.. 23:16 <KjetilK> er 23:16 <KjetilK> er, Formatter::Tidy::HTML 23:17 <jerakeen> _to_ Tidy doesn't make much more sense. 23:17 <KjetilK> well, guess it should really be in HTML::HTML 23:17 <jerakeen> yeah, mine was more a joke than anything else, steal the name 23:18 <jerakeen> I'll do POD tomorrow, because pod is easy, and I'll loko at gutting C::W::F::UseMod/Default or something after that. 23:19 <KjetilK> hehe, so when Kake returns, it is all uploaded to CPAN and working fine... :-) 23:19 <jerakeen> KjetilK: I'm not going to actually upload things until I have a second opinion on the top-level namespace, it still scares me a litt.e 23:20 <KjetilK> ask modules(a)cpan.org? 23:20 <jerakeen> I was going to ask Dr Nick at work 23:20 <perigrin> I think I can get Formatter::PNG::HTML working tonight. 23:21 <jerakeen> perigrin: EVIL EVIL EVIL. And cool. 23:21 <perigrin> Formatter is actually intelligent and descriptive. 23:23 <jerakeen> will, that's that uploaded. 04:09 <perigrin> Hrm, well my ideas/plans for Formatter::PNG::HTML isn't panning out. I can't get Gtk2::MozEmbed to build on my laptop. 04:10 # KjetilK thought about doing F::HTML::Pre but I'm too tired. Think I'm going to bed soon 04:10 <perigrin> Pre? 04:10 <KjetilK> yeah, just stick the text in <pre></pre> 04:11 <KjetilK> and possibly scan for URLs I am not very well at the moment, so my inkling is to give you guys my blessing to just get on with it. So here it is :) Kake

4 8

CGI::Wii 0.61 out
by Kake L Pugh 03 Oct '04

03 Oct '04

CGI::Wiki 0.61 just released - small update to add "ignore_case" option to ->node_exists method. Kake

1 0

Wanted: Another list admin
by Kake L Pugh 02 Oct '04

02 Oct '04

There are over 200 emails waiting in the approval queue for this list - no doubt almost all are spam. I can't actually load the approval page any more because my browser does the spinny pizza thing. Could someone please volunteer to share the list admin task with me? (Please don't volunteer if you would be offended by me turning you down, though.) Kake

1 1

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 October 2004