chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] A call to arms


From: Felix Lange
Subject: Re: [Chicken-users] A call to arms
Date: Wed, 21 Jan 2009 22:26:30 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

>   Most of all, I want people to help harness out the specifications for
>   the "perfect web application framework".
>   My main focus is primarly on the web. Lets hear what you have to say.

You got me started.

To my mind, The Perfect Web Framework (tm) should be
modular. One should be able to arrange content generators
in a tree, and arrange a way for parent generators
to cause the execution of its children, or abort the request.

Presuming that some hidden machinery has arranged a chain 
of generators by matching the incoming url, it would call
a generator, e.g.

(lambda (next)
  (html (div (h1 "some headline)
             (next) ; <<
        )))

with a procedure that invoked the next one in the chain.
Of course, generators could choose not to call down the chain
by simply not applying their argument, which is a nice way to
handle stuff like errors in forms. One could even save the continuation
and recall it later to provide some transactional request logic
The generator matching could be implemented lazily 
(putting the tree recursion into the "next" procedure).

In my very own opinion, 
there are three "scopes of state" associated with webapps.
Request state, session state and persistent state. 

The most appealing idea on request data handling, is
to make it possible to bind parts of the incoming request's data
to variables, allowing you to specify a type and have the 
part parsed, e.g. 

("foo" (integer a) (integer b))

would name a pattern matching paths like "foo/2/3"
and bind a and b to 2 and 3, respectively, in the code that would handle 
the request.

for sessions, i'd consider letting the user define his/her
own session object, e.g. the session state of a counter is
a single integer.
one should be able to attach a different
session object to each conceptual module and arrange 
access to it through some mechanism(maybe parameter objects).

persistent state could be handled the same way except
for some method of migration.
i haven't thought about it that much, but
using git may be a very nice idea. 

i also wish to have fancy html generation (webit? haml?), 
form generator macros that validate and bind field values to variables
and flexible caching and...

%------ snip snip 

felix




reply via email to

[Prev in Thread] Current Thread [Next in Thread]