It should be an extensible web framework written in Scheme. It’s goals are:
There should be no confguration necessary to obtain a simple website. More elaborate scenarios may require configuration, of course.
Templating engines are supposed to be easier to introduce into a web-designer`s workflow. However, in my experience, as the project progresses, the amount of code inserted inside the HTML template makes it difficult for web designers to change, as they become dynamic. Designers should create the prototype, and work with CSS files (and, to a lesser extent, custom javascript). Instead of a templating engine, we should use widgets, described as Scheme procedures. HTML generation is to be handled by a library, and should output correct XHTML strict code.
Rendering pages and partials, as done by the Rails framework is a nice way to create simple websites. However, as they become more complex, they start to have repeated user interface elements, which should be reusable. But, since they are tied to their respective controllers and pages, reuse becomes non-trivial. Widgets should be able to render themselves no matter where they are located in the page. This requires packaging of model - controller - view code inside one atomic block.
If the browser supports it, queries should use Ajax automatically, unless otherwise specified. Usage of Ajax should be transparent to the developer.
When rendering a page, the framework should generate a tree of widgets in a page. Their model requests should be queued and, if applicable, bunched together. Repeated requests should be performed only once. Widgets should also provide a list of files in use. Javascripts and CSS should be minified and bundled. An option to generate a static HTML and cache on disk should be provided. Options for caching generated web pages, SQL and etc using memcached should be considered.
Widgets are chunks of code which gather information from a source (usually a database), process the data and display them to the user. This occurs in response to an event. Events could be:
- URL requests (including Ajax)
- Form posts
Widgets can be subdivided into:
These render requests, usually in response to an event. They can gather information from a variety of sources (memcached, mysql, webservices, filesystem files, sockets, etc), process and then display them. Their display is not required to be HTML - could be Javascript, XML, plain text, binary (for instance, to output images).
These contain other widgets. They are not visible. A page is a Container Widget. As of now ([2009-06-27 Sat]), pages are not special.
These are usually (but not always) HTML forms. Their purpose it to gather input data, validate and process. Rendering the results is usually accomplished by another Renderer widget. This one renders the form (and validation results, if required).
Receives CGI requests, break down the environment variables and stuff them inside a structure. Parameter validation and escaping can be done here.
Matches rules to container widgets, passing any required parameters.
SEXPR based XHTML strict renderer.