Re: Xavante/Cgilua: custom handler - please critique

[Javier Guerra <javier@...>]

On Monday 15 August 2005 1:17 am, William Trenker wrote:
> > special-purpose code is cheaper; and as you go, you'll create your own
> > library of helper functions.  (we're still missing a lot of these)
>
> Of course the ease of writing helpers / special-purpose-code depends
> significantly on having a rich API from the httpd / cgi core.

sure, but make it "httpd core", i'm not talking about CGI

> > well, i've just coded cookies and session modules for Xavante, to be used
> > from handlers, without CGILua.
>
> Hmm.  I'm surprised.  Why not refactor CGILua to expose more of its
> functionality in its API and use that within Xavante?  Why rewrite
> code that's already available?

i do look into the CGILua code to see how it's done there, but usuall can't 
reuse it because it's a tight package, and i want xavante to be usable even 
without it.

and as for using the Xavante code, remember that CGILua is far older than 
Xavante, and it has to work (almost) identically with any kind of launcher.  
the old CGI ones are particularly limited.

> > and as for ".lp CGILua scripts" i've just added the capability to write
> > handlers using the same syntax as .lp   note that these aren't CGILua
> > .lp! just a neat way to write xavante handlers
>
> Meaning that such a xavante handler can include parameter substitution
> (<%= cgi.mytextinput %>)?  I don't understand. (Is this new code in
> cvs?)

it's not yet in CVS, it still hasn't been reviwed by anyone....

and using these new 'handler pages' (still no neat name) you don't get CGILua 
functionality; you use req,res as in any other handler.  it's just a new 
syntax for getting content into the hanlder.

> So xavante is evolving from a web server with built-in cgi scripting
> support towards a web applications framework?  That sounds very
> promising.

yep! but i wouldn't call it cgi scripting; all code is compiled at launch 
time.  i see it like this:  CGI, server pages and such all evolved from the 
need to put code in the old 'one page, one file' mapping.  this is a more 
'code oriented' way of developing, calling content from the app and not the 
other way around.

-- 
Javier

Attachment: pgpcMiW3eEnMO.pgp
Description: PGP signature