From: Richard Jones <rich@annexia.org>
Cc: caml-list@inria.fr, "HENRIKSON, JEFFREY" <JEFHEN@SAFECO.com>
Subject: Re: [Caml-list] environment idiom
Date: Fri, 10 Dec 2004 12:13:06 +0000 [thread overview]
Message-ID: <20041210121306.GB29002@annexia.org> (raw)
In-Reply-To: <41B97FD7.50309@andrej.com>
[-- Attachment #1: Type: text/plain, Size: 2464 bytes --]
The specific data that Jeff wants to pass around are:
cgi - The CGI environment
r - The Apache request_rec (in fact, cgi#request == request,
but sometimes it's slightly more convenient to have it as
a separate parameter)
dbh - The database handle
hostid - The host ID (COCANWIKI supports multiple virtual hosts)
host - The "host object" which contains other host-related info
user - The "user object" which contains info on the logged-in user
In theory one can derive all of the above from just cgi and dbh, but
it's very inefficient to do this because it would require making
database requests. For practical and efficiency reasons COCANWIKI
derives the hostid, host and user with just 2 database queries at the
beginning of every HTTP request.
COCANWIKI is fairly modular. For instance it has a library function
to handle the parsing of the Wiki markup, prototyped (currently) as:
Wikilib.xhtml_of_content : Dbi.connection -> int (*hostid*) ->
string (*markup*) -> string (*XHTML*)
The reason that this function needs a database handle and hostid is
because parsing Wiki markup is sensitive to the content of the
database. If someone writes [[Page]] we need to write different
things depending on whether there is a page in the database called
"Page".
Jeff wants to extend xhtml_of_content in a way that also requires
browser sniffing (ie. fetching the User-Agent header from the Apache
request_rec object). So we need another parameter. But
xhtml_of_content is far from being a monolithic function at the
moment. It is, in fact, divided up into many many smaller functions
which handle different parts of the parsing, and for various (wrong)
reasons those are written as separate, not nested functions.
The same problem of needing to pass around chains of extra
"environment" arguments occurs all over in these libraries.
Personally I really like Jeff's "anonymous object" trick, because the
compiler works out for you which "environment" bits are needed by the
library function, and you can just make the right object on the fly
when calling the function.
Rich.
--
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
>>> http://www.team-notepad.com/ - collaboration tools for teams <<<
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://subjectlink.com/ - Lesson plans and source material for teachers
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-12-10 12:13 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-09 2:07 HENRIKSON, JEFFREY
2004-12-09 4:47 ` [Caml-list] " Jacques Garrigue
2004-12-09 6:02 ` Michael Walter
2004-12-09 11:28 ` Jacques Garrigue
2004-12-09 20:02 ` pad
2004-12-09 23:11 ` Jacques Garrigue
2004-12-10 2:30 ` skaller
2004-12-09 9:09 ` Richard Jones
2004-12-09 13:12 ` [Caml-list] " Ville-Pertti Keinonen
2004-12-10 11:59 ` Richard Jones
2004-12-10 10:52 ` [Caml-list] " Andrej Bauer
2004-12-10 12:13 ` Richard Jones [this message]
2004-12-10 23:35 ` Jacques Garrigue
2004-12-11 2:30 ` skaller
2004-12-11 14:31 ` Andrej Bauer
2004-12-11 18:13 ` Markus Mottl
2004-12-11 23:56 ` skaller
2004-12-12 2:36 ` William Lovas
2004-12-12 5:33 ` skaller
2004-12-12 19:09 ` Michael Walter
2004-12-13 0:48 ` skaller
2004-12-13 2:03 ` Michael Walter
2004-12-13 2:05 ` Michael Walter
[not found] ` <877e9a170412121844b633bb8@mail.gmail.com>
2004-12-13 2:45 ` Michael Walter
2004-12-13 6:18 ` skaller
2004-12-13 7:08 ` skaller
2004-12-13 9:56 ` Michael Walter
2004-12-13 12:59 ` skaller
2004-12-13 8:56 ` Thomas Fischbacher
2004-12-13 9:21 ` Jacques Garrigue
2004-12-13 10:05 ` Michael Walter
2004-12-13 10:29 ` Thomas Fischbacher
2004-12-13 21:16 ` Michael Walter
2004-12-13 10:20 ` Thomas Fischbacher
2004-12-13 12:09 ` Jacques Garrigue
2004-12-13 12:48 ` Thomas Fischbacher
2004-12-13 14:09 ` skaller
2004-12-13 21:39 ` Michael Walter
2004-12-13 13:22 ` skaller
2004-12-13 16:54 ` Marcin 'Qrczak' Kowalczyk
2004-12-13 18:44 ` Thomas Fischbacher
2004-12-13 10:11 ` Michael Walter
2004-12-13 11:46 ` skaller
2004-12-13 5:41 ` skaller
2004-12-13 9:29 ` Michael Walter
2004-12-13 12:30 ` skaller
2004-12-13 13:49 ` Martin Berger
2004-12-12 23:03 ` Thomas Fischbacher
2004-12-13 1:26 ` skaller
2004-12-13 8:37 ` Thomas Fischbacher
2004-12-13 10:53 ` skaller
2004-12-13 11:38 ` Martin Berger
2004-12-13 13:33 ` skaller
2004-12-13 12:01 ` Thomas Fischbacher
2004-12-13 13:41 ` skaller
2004-12-11 23:29 ` skaller
2004-12-12 0:21 ` Jacques Carette
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041210121306.GB29002@annexia.org \
--to=rich@annexia.org \
--cc=JEFHEN@SAFECO.com \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox