Re: [Chicken-users] Suggestion for new egg: Wings!

[Ivan Raikov]

Hello,

    The design you are describing still sounds very much based on
imperative programming, not to mention that having one global
environment with all your web variables is not particularly scalable
or secure. I think it might be better to go for a Zope-like approach,
where the resources are organized in a tree (or some other type of
hierarchical structure), which has to be traversed by the client from
the top down, in order to access the different resources. If I
remember correctly, a node in the Zope tree could be an authentication
node, which needs to be passed correct credentials in order for it to
provide the nodes in its subtree. For example, you could have the
following structure (/ is the document root):

 /
 |
 |--index.html
 |
 |--auth1--page1.html
    |
    |--auth2--page2.html        

If the client accesses /index.html it receives the contents of that
object without authentication, but if it accesses /auth1/page1.html,
it has to authenticate through the auth1 authentication object, and so
on. I think that this kind of tree traversal approach would give you
so much more flexibility, because the subtrees in the resource tree
don't have to be all loaded in memory at once, so they can be
dynamically generated, distributed across servers, etc, etc.  So
perhaps a good first step would be to write a generic resource tree
library. 


   -Ivan

Alaric Snell-Pym <address@hidden> writes:

> Ok. Those of you who lurk in #chicken on irc.freenode.net will
> probably be familiar with how we all like to main about Ruby on Rails.
>
> The conclusion I came to is this:
>
> 1) A web app could consist of a .scm file that loads spiffy and third-
> party extensions, then proceeds to load or define application-
> specific business logic procedures, thus leading to a nice global
> environment full of tools, and registering resources of a more
> dynamic nature in a hash table.
>
> The framework defines a parameter, wings-environment, which is bound
> to a closure that accepts a key and returns the value associated with
> that key in the global hash table, or nil otherwise.
>
> The reason for this will become clear in a moment.
>
> 2) The web app finally, having set up its environment, starts spiffy
> serving files out of a document root directory.
>
> 3) These files contain the frontend of the application. Static files
> (CSS, HTML, images, etc), as well as files that spiffy knows to
> handle specially. All of the existing spiffy handlers will fit into
> the Wings model OK, but there's a few more I have in mind. More on
> those later.
>
> 4) There are web app frameworks that are "continuation based" or
> "widget based" or various other paradigms. Each of these paradigms is
> nice for some things, but sucks for others. Continuation systems are
> great for things with a very sequential page flow, like multi-page
> signup processes and complex operations. Widget systems are great
> because you can bind the widgets to your data sources easily.
> Frameworks like Rails are based around an object-relational mapping
> to SQL databases, and if you use that supplied data store, it
> automates a load of stuff to do with generating pages from data in
> SQL or forms that edit same; but if you want to edit data stored in
> other kinds of database, you have to do much more work yourself. Etc.