Re: [Chicken-users] dynamic web resources?

[Mario Domenech Goulart]

Hello Andreas,

On Tue, 17 Oct 2006 20:16:21 +0200 Andreas Zwinkau <address@hidden> wrote:

> > I'm not sure I understand.  What do you mean "variables" in this
> > context?
> Uh, sorry. I was talking about "arguments". How does your
> define-callable-url react on /add, /add/1 and /add/1/2? For summation it
> may be ok to have a unspecified number of arguments, but consider
> webapps like blogs or wikis. This will mean checking for number of
> arguments in every callable-url? Example: "/names/show-some-name/x/y/z"

The procedures defined with define-callable-url are actually regular
Scheme procedures.  So, if they are called with an unexpected number
of arguments, an error would be raised.  If they are supposed to
handle arbitrary number of arguments, they have to be defined
accordingly.


> I also dislike the hidden state with all this add-resource or
> define-callable-url. Maybe this is only me coming from Pythonland,
> where "explicit is better than implicit". I can't *see* how start-server
> finds things from add-resource or define-callable-url, but rather
> assume another global namespace for resources. Passing an
> explicit handler (like my dispatch-rules) looks better to me. This is
> opinioniated, so what do you think?

Actually the http:add-resource is wrapped by the `register-dispatcher'
procedure, which adds the resource using a regex as argument.
Something like:

  (register-dispatcher "/callables"
     ...
     (http:add-resource "/callables/.*")
     ...)

Thus, requests for paths under "callables" would be treated as
procedure calls.

Right now I'm working on this namespace thing.  I'm using environments
to enclose procedures defined with define-callable-url.  So, each
environment corresponds to something like a namespace.  In practice,
there's a hash table mapping a name (the path used by
`register-dispatcher') to an environment which will enclose the
procedures.

If I understand correctly, you prefer the idea of having procedures
defined to handle specific HTTP method's variables (e.g., POST, GET
etc).  So, a procedure defined to handle POST variables should not
work for GET variables, right?

Best wishes,
Mario