CGI-Wiki-dev January 2005

cgi-wiki-dev@earth.li

3 participants
4 discussions

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

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

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 January 2005