English version
Accueil     À propos     Téléchargement     Ressources     Contactez-nous    

Ce site est rarement mis à jour. Pour les informations les plus récentes, rendez-vous sur le nouveau site OCaml à l'adresse ocaml.org.

Browse thread
environment idiom
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-12-10 (12:13)
From: Richard Jones <rich@a...>
Subject: Re: [Caml-list] environment idiom
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

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.


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