Rules: Home | Background | Example | To-Do | Goals | Plan

Historical background

The rule engine I'm building is inspired by the one from WebObjects' Direct To Web framework.

I want to be really clear about something up front - the Direct To Web framework was really two things: The Rule System, and the Direct To Web templates (the "database publishing" system).

The Direct To Web templates use the rule engine of course, but using the rule engine doesn't require using the Direct To Web templates. I am interested in seeing the rule engine used for use cases other than scaffolding model objects.

Starting with the D2W-like pages is a useful way for me to get started with using the new rule engine I've written, but it's also risky because I don't want developers to think that the rule engine is only useful for customizing scaffold templates.

Direct To Web made publishing databases on the web a trivial exercise, by creating pages to query, list, inspect, and edit objects, introspecting your model at runtime to tailor its display. It came with three "looks" (skins). Each skin had templates for all of the tasks. Note that tasks are a Direct To Web concept, not a concept you have to use to take advantage of the rule engine. However, many web applications are task-oriented anyway, so it was helpful to use and adapt the Direct To Web templates in your applications.

Direct To Web included nine tasks:


queryall: thispage presented a simple search interface for all of your application's entities.

query: this page presented a search interface for a particular entity.

list: this page presented a paginated/sortable table listing of pages of a particular entity type. The query* pages took you to list pages.

inspect: this page presented each property of a single object of a particular entity.

edit: this page presented a form for editing each property of a single object of a particular entity. It supported editing attributes and relationships (to-one, to-many and many-to-many).

editRelationship: this page presented a way to choose objects for a to-many relationship of another object.

select: this page is like a list page but it also had an extra column with a "select" button in each row. Useful for choosing an object for a to-one relationship.

confirm: this page presented a confirmation message with buttons to cancel or confirm an action, such as deleting an object.

error: this page presented an error message with a button to return (to some page).

For the end user, this is similar to Rails' scaffolding, except no code is generated to render the pages - instead, generic templates consult the rule engine to get information from the developer about how they should display themselves and how to behave when actions are taken. And Direct To Web contained an intelligent set of rules that reflect on the model to provide the defaults.

Therefore, from the developer's perspective it's a completely different experience. Instead of being responsible for maintaining boatloads of generated code, the developer only instructs the system how to modify itself from the baseline and provide any custom behaviour necessary to implement their requirements.

I used the word "generic" above intentionally - a generic template that uses a rule engine as a parameterization mechanism is truly reusable, just like a generic class in Java or a template in C++. Just like a generic array is better than a non-generic array or an array designed to hold only one type, a generic scaffold is better than a scaffold designed to work with only one type, at the time the scaffold was generated.

Your model will evolve. To keep DRY, so should your scaffolds.