Why Do This

This started out as a simple project to allow editors to include the contents of a text file within Episerver content.

That CMS provides "blocks," which are reusable content elements. I wrote a simple block into which an editor could specify the path to a file on the file system. The block would read the contents of the file and dump it into the page. It was essentially a server-side file include for content editors.

Then I got to thinking (always dangerous) that some files might need to have newlines replaced with BR tags, and how would I specify that? And what if the file wasn't local? How would I specify a remote file? And what if it was XML -- could I specify a transform?

And the idea of a text filter pipeline was born. To support this, I needed to come up with language constructs, and that's when I started parsing commands. And then I found I could enable some really neat functionality by tweaking and tuning and making small changes.

And when the snowball finally came to a rest at the bottom of the hill, you had, well, this.

There is some precedent here:

• MediaWiki, the wiki software behind Wikipedia, allows multiple ways of embedding scripts:
  • The Scribunto extension allows scripting in Lua.
  • The Widgets extension allows scripting through Smarty templates.
  • The Cargo extension allows the embedding of queries and content through a SQL-like syntax.
  • The External Data extension provides multiple ways of obtaining and transforming outside data
  • I could go on and on. Seriously, for a system that makes you think it just holds simple pages, you'd be amazed at the level of functionality available there.
• Mindtouch supports something they call Dekiscript
• Drupal has always allowed some editorial/administrative PHP scripting (though, not sandboxed)
• WordPress supports Shortcodes, which can perform some logic
• TERMINALFOUR allows template editing from the interface, and those templates can execute server-side JavaScript via Rhino
• Umbraco allows the editing of templates from the interface, and those templates are written in Razor (however, as I mention in Alternatives this can't easily be sandboxed)

The constant challenge with this type of project is knowing when to stop. At what point are you simply inventing a new programming language? When do you cross the line from simple and useful to pointless and redundant? And when do you cross another line into something which is potentially dangerous in the hands of non-programmers?

Consider some of the examples -- they really have nothing to do with text filtering. The pipeline is executed without input, the XML is obtained in the first step, and content is extracted then formatted. In this case, we're not filtering at all. We're really edging into a simplistic procedural programming language. How far is too far? At what point does Alan Turing roll over in his grave?

I don't have an answer for that (hell, we may have crossed the line already). I leave it to you to judge.

I'll finish by mentioning a talk by Spore developer Chaim Gingold at the 2007 Game Developers Conference. The talk was entitled "Spore's Magic Crayons" and the presented the idea software should perform like the titular tool in Harold and the Purple Crayon using which our hero could draw something and have it immediately come to life.

That's the primary, philosophical use case of Denina -- give editors magic crayons. Let editors indulge their creativity by using a simple toolset to glue ideas together and create new things. Of course, with power comes responsibility, and guided by an experienced developer, the hope is that an editor can expand beyond just original content to mix-and-match other sources to create new content products.

I hope I have succeeded at some level.

Implement with care.