slate blog

One of the first big decisions we made with slate was to avoid using a custom templating language for site themes. When the project first started in PHP, I evaluated a number of templating systems such as Smarty, but we came to the conclusion that it simply wasn’t necessary. Aside from the potential overhead, it just wasn’t worth learning another language. Since we would have to teach our designer to write some code, it might as well be the native language of the system.

Fast forward to the rebuild of the system in Ruby on Rails. Templates were a bit messy early on, as I had essentially ported them from PHP to Ruby. However, after rewriting the page building module (named Pagebuilder, actually), and adding in a number of helpers, the templates became very easy to develop and maintain. They became even easier when I literally dropped two tables from the PHP implementation. These tables stored information about the available templates for a theme, and information about what areas of the template were editable. Removing these tables simplified the whole process so much that I wanted to kick myself for not thinking of it sooner.

With the addition of the helpers and the removal of those pesky tables, we won big time. We won because we took out the configuration step completely for themes, which meant that adding a new editable area to a template was as simple as adding a single helper call. We also won because now we can switch a site’s theme without worrying about database mappings.

One small problem

There was, however, one small problem with our solution: our designer needed a way to test these themes on his computer, and it would be overkill to have the entire project on his machine. Plus, it would add unnecessary configuration into the mix again, having to set up the machine to run slate.

Mock builder

My solution was to build an extremely dumbed down version of slate (like, two Ruby files) that would mimic the helpers used in templates. I named the system mock_builder. Here’s a basic run-down of the features/implementation:

• WEBrick server with a custom ERBHandler
• mocks of all necessary helper methods used by templates
• dummy content generator (using Lorem Ipsum)
• user-defined content and navigation via mock_data.yml
• style guide support (to ensure we style things like visited links, tables, etc.)
• user-friendly exception handling
• easy navigation of templates within a theme
• works “out-of-the-box” (uses only Ruby core and standard library)

Mock builder has greatly simplified the process of developing themes for slate. But beyond that, it’s just cool ;-)