Extensible formats system

[lilith]

I'm looking at ways to give Nesta an extensible formats system so that plugins can define new content formats (or just add support for additional file extensions for the same ones).

Tilt has a pretty refined interface for this, and while I don't see any way to piggyback on Tilt for heading and body parsing, I'm currently thinking of simply cloning Tilt's 'register' and 'prefer' API for Nesta::Formats. See https://github.com/rtomayko/tilt/blob/master/lib/tilt.rb

Tilt's full API weighs in around 100 LOC. That's a lot considering the code for parsing all the formats currently weighs 25 loc.

Should I forego the full 'register'', 'prefer', & fallbacks, and simply have a last-registered-wins system, with at most 1 handler per file extension? Or should I stick with Tilt's API?

Without a clean way to add formats I can't really migrate away from a custom nesta branch and start using plugins...

[lilith]

After reviewing things, I noticed tilt uses string keys instead of symbols. I also couldn't think of a reason to justify needing fallback capabilities, although that doesn't mean there isn't one.... perhaps a future format parser will need a dependency?

Please provide suggestions, opinions, and point out the flaws in my code, here: https://gist.github.com/1226852

[gma]

I haven't looked into the code yet, but what I'm hoping to be able to do on this front is just to hand the job of choosing rendering libraries off to tilt. So the haml and erb helper methods would be fronted by something called render_view :name that would check for files in the views folders that match the pattern name.*.

The render_view helper would then just try and give it to tilt to deal with, without worrying too much what the extension was. People would then be able to adjust which parser gets used simply by calling Tilt.prefer themselves in their app.rb file.

Am I missing something important here? I noticed your gist has code for stripping the metadata off. I've ignored that bit for sure.

[gma]

Also see #73; not the same problem, but worth considering while working on this one.

[lilith]

The formats system I proposed is independent of Tilt's rendering choices. It's just there to (a) inform Nesta which file extensions to search for when looking for content, (b) provide parsing code to extract the header from a file based on format, (c) provide parsing code for extracting the body, and (eventually, maybe) (d), allow metadata parsing to customized for certain formats.

[gma]

@nathanaeljones Do you still need this? I'm not in a position to do anything about it for the foreseeable future (i.e. it won't hit master any time soon) and I'm trying to decide whether to close it for the moment.

[gma]

I'm tidying up and closing issues that haven't seen any activity, or where it's not clear they're still required. If you still need/want this, feel free to re-open…