Plain ol' HTML content in 'dynamic/'
When trying to make some finishing touches to my Frank setup, I decided it might be a nice idea to switch all my article content files (which literally only contain the article content, and a little meta-data) away from ERB, in case some of my content, all of which is written in plain HTML, contained a "<%" or "<%=" which would screw everything up. Unfortunately switching all my content files over from ".erb" and ".haml" to ".html" resulted in the following when exporting:
frank-1.0.12/lib/frank/base.rb:184:in
tilt': undefined methodnew' for nil:NilClass (NoMethodError)
Switching them back to ERB works fine, but there's still that risk of screw-ups if I accidentally end up writing some ERB when writing HTML content (perhaps in a code snippet since my static site is to do with programming). This content still needs meta-data of course, but unfortunately these only seem to be supported by Frank in the templating frameworks (ERB and HAML) as well as Markdown (my posts aren't written in Markdown, so even though it's awesome for content writing, it's not any good here).
Some support for plain HTML files with YAML META sections would be awesome.
I was planning on making static and dynamic be one folder in the next release, wouldn't be difficult to make html support the meta data header. Not sure if there is a good reason to do it, or if there would be any weird issues with it.
I'd recommend sticking with erb. It gives you flexibility if you need it later on, you should be able to escape the erb tags if you ever needed to use them for code snippets. http://stackoverflow.com/questions/2322413/how-do-i-escape-erb-code-in-fixtures
Not sure what you mean by having the risk of screw-ups? You'll know immediately if you have a problem (during export/compile) and you'll fix it before you roll out any code.
Would be awesome to see the static and dynamic folders combined.
Good point about ERB, I think I'll stick with it, if nothing else, for the small number of situations in which having "dynamic" content in regular content files could be useful. And you're right, it can't really cause any screw-ups unless I start doing articles that include ERB in code snippets, in which case I might not notice the ERB replacement in the file.
I think ERB is definitely the best solution for now anyway, I'm not likely to be using ERB in my article code snippets. Thanks!
Static + Dynamic folders combined would be awesome! If you can handle the differenciation between which content to parse via tilt, but also which ones to layout and such with YAMl metadata.
I wanna do this, I also wanna support stacking the templating languages via extension, so blah.md.erb would get parsed by erb first and then markdown.