Fabulator Update

Image via Wikipedia

I don’t have any on-line documentation of the language and extension API yet, but I should in a month or two. June at the latest. I’m redesigning and rebuilding the TAMU College of Liberal Arts Digital Humanities Program website. The new site will go live around June.

The current core engine has three complementary systems: the XML framework for defining the parts of an application, the XML actions that can be run, and an expression language for manipulating the data tree in the application. The framework sets up the overall application, view, and transition contexts for the actions. The core actions manage control flow and data transformation. The expression language can be used to perform calculations, similar to XPath. The system is designed to act on application data similarly to how XSLT does when manipulating XML documents.

In addition to the core engine, I’m splitting the RDF manipulation out into its own extension and starting a workflow management extension. By summer, we should have the core engine and the two extensions fairly polished.

The beauty of this system is that I can add capabilities that any project can use, and add them in a way that lets me focus on the capability instead of all of the tasks that I would have to worry about in a general, standalone application that provided the same capability. For example, I’m planning on developing an extension to manage all of the data calculations needed to support a faceted browser. If I do it right, all I’ll have to worry about is providing the calculations. The core engine will be able to tie everything together easily. In addition, all the calculations should be generic enough that I can use them for something other than a faceted browser.

This engine allows you to build an interactive, database-backed application without having to do any of the repetitive basic work that traditionally goes into such an application. No worrying about filtering and constraining data from the browser (it’s trivial to specify the filters and constraints and not worry about how it’s done), no getting the right view in the right place in the code, no worrying about people jumping into the middle of a process, no worrying about what to do with data between requests when you need to collect more data before doing something, no worrying about managing a relational database schema. Everything just works with descriptions of what you want.

The next steps will be to look at several projects using this system and see where I’m repeating myself in those projects. Then, following the DRY principle, reduce the redundancy in the descriptions. For example, if I have the same RDF pattern over and over again for a particular object type (a person, for instance), then I should have somewhere to describe that pattern so I can just say that I want all of the people and not worry about what the pattern looks like. At the same time, I should be able to say that I want all of the people as well as some additional information without jumping through too many hoops or worrying about how the data is stored.