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 <head> 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>, <a href="amazon:...">, 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?
on 2007-02-14 09:55