Two step textfiltering

I can’t remember if I’d written about this on the list before, so, at
risk of repeating myself, here’s what I’ve been thinking about recently.

So, I’ve been thinking about textfiltering. It’s something I do quite
a lot of because I’m still not happy with it.

The basic issue with textfiltering is that some macros need access to
controller structures (routing, the section, stuff). Meanwhile
the filters that do the heavy lifting of converting from the raw
content to HTML are usually implemented by external libraries that
know nothing and care less about Rails and can be run purely in the
model.

We already have some kind of separation between these things in that
we have Filters and Pre and Post Macro filters.

I’m thinking of ditching Pre filters entirely and reworking PostMacros
to use a registry approach, keyed on CSS Selectors (using Hpricot for
the time being). The way it would work goes like this:

A content model has a filter which is used to go from plain text to
‘HTML’ but that HTML can still contain macro tags (typo:code, , that sort of thing). This is the text served up by
object.html(:all) or whatever.

Meanwhile, our macros plugins have registered themselves with Typo:

Blog.add_callback(‘typo:code’, Plugin::TypoCode)
Blog.add_callback(’[href^=amazon:]’, Plugin::Amazon)

Then, once it’s built the HTML for the page (possibly even after the
layout’s been applied, but I’m not entirely sure how possible that is)
the controller runs HPricot over the generated HTML and then traverses
it looking for registered selectors and calls back to any plugins that
get triggered. It should be possible to do this in a single pass,
calling the ‘innermost’ hits first, which solves any ordering issues
we might have with when macros need to run. The Plugins would get run
in a context that gives them access to helpers like ‘url_for’ etc.

Note that this sort of plugin framework has possibilities for more
than just textfilters. There’s nothing to stop you hooking the body
tag and using that to trigger anything you like. One possibility would
be hooking into the .comment-box div and adding your own captcha
code. Combine that with a hook into the comment controller (I’ve not
worked out what that bit needs to look like yet) and Robert is your
parent’s sibling.

I’ve been giving some idle thought to theming as well. It seems that
once we have this sort of API in place, there would be nothing to stop
us adding the capability for themes to come with their own filters.

Thoughts? Have I missed something obvious? Do I have spinach on my
teeth?