Monday, October 16, 2006

Working on a Factor web framework

Factor has some components of a web framework already:
  • contrib/httpd - basic request processing
  • contrib/embedded - reads a file, evaluates Factor code between <% and %>, and dumps the result
  • contrib/xml

I'm working on a web framework named Furnace which builds on these components and adds features to help construct typical CRUD web applications. It is located in contrib/furnace and is almost non-existent at this point, but my goals are to have it do the following:
  • Action processing, forwarding
  • Form validation
  • HTML component management
  • Templating

I still haven't decided how templating will work in the end:
  • Right now I'm using contrib/embedded because it is simple and the code is there
  • Pure-HTML templates marked up with 'id' attributes (like Wicket)
  • XML templates, mixing HTML with custom Factor tags but no Factor code

The last two approaches have potential to be cleaner, because right now the contrib/embedded templates feel boilerplate-ish:
<tr><th>Paste by:</th><td><% "author" get write %></td></tr>
<tr><th>Channel:</th><td><% "channel" get write %></td></tr>
<tr><th>Created:</th><td><% "date" get write %></td></tr>

I think some custom tag, or "id" attributes on the <td> tags would be prettier.

So far the example web app I've been building in parallel with the framework is a pastebin. Once the framework has enough features to make the pastebin support all the necessary features (navigation, validation, etc) with pleasing and simple code, I want to build a wiki and blog, and then eat my own dog food, using Factor to host this web log. I expect these CRUD-style web apps to be trivial to build once the framework is done.

Note that I haven't said anything about persistence yet. For a pastebin, a global variable holding a list of tuples is enough, but obviously for a wiki or weblog this is horribly insufficient. We have code in contrib for interfacing with PostgreSQL and SQLite, Chris Double has a simple O/R mapper that maps Factor tuples to SQLite table rows, and Doug Coleman has expressed interest in extending this to a more general O/R mapper. Pending some kind of miracle whereby an object database written in Factor suddenly appears, the preferred method of persistence in Furnace will be an SQL database together with an O/R mapper.

I plan on integrating Chris Double's work on continuation-based control flow, however the standard "REST" style will be preferred in most cases. Chris Double has also been working on a Factor library for writing web applications using the Comet style. I know very little about JavaScript, but integrating this with Furnace, along with other client-side features such as validation and completion would be nice.


Anonymous said...

Here's a bug for your ear:

No, the point is not the cool JS or the AJAX, it's the state.

Slava Pestov said...

I've seen this before, its really neat. What do you mean by state?

Anonymous said...

Client state is preserved. Clean. No extra programming. Client can use back-button.

Anonymous said... explains it better than I can.

The Javascript and AJAX are great, but the way client session state is natively preserved is what makes Seaside so cool.

Anyone developing a web framework should take a look and see what is being done with this.

Anonymous said...

Seaside is very nice, but it is query crappy when it comes to SEO, which is very important these days. There are hacks to 'fix' the problems, but as far as I have seen they are not that solid. Spiders index the seaside sites with the ?_s=... state variable in it. Which not only looks clumsy, but, in fact, is clumsy. Don't copy that bad practice.

Anonymous said...

I said 'query' but meant 'quite' ofcourse :) (progging + commenting at the same time => not good?)