slate blog

Yesterday I added a live demo of our Textile Editor Helper plugin. That awesomeness was planned. What wasn’t planned, however, was the interesting implementation.

Let me explain. The demo consists of a form with the editor and a preview button. The preview button POSTs the textile and returns the HTML version. Running this site in slate posed an interesting problem: where will the form POST? Sites run in slate do not have the luxury of custom routes, etc. because the public site consists of page URL paths (and “anchors” to attach behavior such as blogs to a given page). This means all routes on the public side boil down to a “catch-all” route. Thus, I couldn’t simply add a new controller/action and be done with it. That solution also wouldn’t work because it would couple the site to slate in a very messy way that I wouldn never be comfortable with.

The solution sort of just “happened.” Call it programming by coincidence if you want, but I’m tagging it as unplanned awesomeness.

What was the solution? I had created a new template for the demo page, and templates in our system are simply ERB files, meaning I can add whatever Ruby code I want. Including... basic form processing :) So, the form POSTs to itself, which slate happily renders because the URL is a valid page. The template for the demo page essentially consists of a huge if/else which checks to see if POST parameters were passed along. If so, it gets RedCloth’ed and spit out.

The fact that this works really opens up a world of potential. Themes in slate could become mini applications if necessary and could implement their own logic. Awesome.