[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] CGILua 5.0 Beta Released
- From: Javier Guerra <javier@...>
- Date: Thu, 16 Dec 2004 11:33:01 -0500
On Thursday 16 December 2004 9:20 am, Tomas wrote:
> There is subtle trick you might pay attention. Despite
> the launcher you choose, CGILua always run from the beginning,
> therefore, unless you decide to change the internal structure,
> you will have to put the above code inside cgilua/config.lua.
> This way, the code will be executed before CGILua decides what
> handler to call. Also you will have to register all the functions
> there, for the same reason.
right, i haven't tried this code yet (it was just off the top of my head). i
realized that the url-funcions table should be created before most of CGILua.
config.lua might be a good place to put it.
or maybe i could store that table with the Stable API?
something like this:
-- store an empty table
stable.set ('ulrfuncs', {})
-- register (sub)dispatcher
cgilua.addscripthandler ('lf', function (path) return stable.get ('urlfuncs')
[path]() end )
-- to register new funcs
function registerurlfunc (path,func)
stable.get('urlfuncs')[path]=func
end
lots of error checks missing.....
> > maybe i would modify the fastcgi launcher to get rid of the venv() for
> > each call... i still feel that it negates most of the advantages of the
> > persistent state of fastCGI
>
> You can do that but be careful because CGILua expects to
> run in a clean environment.
> Tomas
that experiment would be after i feel comfortable with the other additions.
i still don't really understand why is it desirable to isolate each request
with a venv(), what would you think about doing just one venv() surrounding
the main request loop in the fastcgi launcher?
--
Javier
Attachment:
pgpB4hZ1wsUww.pgp
Description: PGP signature