Factor Language Blog

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.