About MasterView

Why another templating engine?

In short, I needed a way to be able to use a WYSIWYG editor to design/layout my rails pages and didn't want to give up the power and productivity of layouts, partials, and rails helpers. I needed to be able to create html templates quickly that could be handed off to a graphic designer for complex styling, and then use those html templates directly in the project. I also needed to be able to take existing html prototypes and easily make them real. I wanted to be able to give these html templates back to the designer at anytime throughout the project if the style or layout needs to be updated. The existing templating solutions did not meet all my goals or desired operation. For more information, read the background story below.

Goals

Create/extend a template engine for rails that would be XHTML friendly and thus could be edited/styled with a WYSIWYG HTML editor even late in development without breaking template.
Keep it simple. DRY. No extra config files, simple syntax with ruby flavor.
Design it specifically for ruby and rails. Use the full power and not be limited in its capabilities over what can be done with ERb
Utilize layouts, partials, and rails html helpers.
Reduce complexity, work with existing rails code, no extra view logic or hashes than what is used by ERb. Scaffold generate initial templates or work from existing html prototype.
Production ready generated templates - Make generated scaffolding templates useable for production. Build in proper structure and style hooks. Provide simple CSS for style and color usage. Fully generate labels and fields so that it will be simple to reorder or remove things from views there by eliminating much of the re-work necessary to build out real-world views.
Reduce the numbers of files, simplifying editing. Define partials and layouts naturally right in the template, no need to go to another file.
Preview in browser without running an app. Allow for dummy data in the template so that the page can be viewed and styled independently of the application.
Performance equal to ERb

Background story

I came from a Java Struts environment when I was introduced to Ruby. I was just in the process of evaluating Tapestry and JSF when I learned about Rails. Ruby and Rails changed my world forever. I had to however drop many of my bad habits aquired from years of Java and C++ work. I had to embrace the new ideas and approach things now with a different mindset. (If you ever have a chance to hear Dave Thomas speak, you will know what I mean. He has a wonderfully entertaining yet enlightening way of illustrating this.)

After learning the Ruby and Rails way, (Thank you Matz and DHH for such wonderful gifts to the world) I was amazed at how productive this environment is. Programming was fun once again, and everything you do in Ruby or Rails is easier than any other language or framework I have ever seen. Even taking into account having to learn something new, I was still far more productive than ever before. The only thing that I felt that could be done better, was to have a nice html friendly templating engine so that designers and developers could work collaboratively together on a project. The designers could style and layout the pages with their WYSIWYG HTML editors and developers would have the full power of Ruby and Rails without having to jump through extra hoops to use them. I looked at the available html template engines to see if anything fit with my style. I was disappointed with each of them, mainly because they all made it harder than straight ERb (rhtml) and were not able to use layouts and partials easily.

After all the hard work so many people have put into Ruby and Rails, I wanted to see if there was anyway I could contribute as well, maybe extending one of the existing template projects to have the ideal functionality I was striving for. I wanted something to make my own web development even more productive. However after reviewing each of them and even getting into the source code, the closest ones seemed to be Amrita2, Liquid, and Kwartz. Unfortunately it was not going to be easy to add the functionality and usability I desired.

During my research I learned that many of the rails gurus were putting down html template engines because they felt that they handicapped the developer severely, namely by not taking advantage of rails layouts, partials, and html helpers. After doing some projects with ERb (rhtml) I realized that they were right. I too did not want to give up any of that power either. I also didn’t want to create a bunch of extra code or config to use the templates (extra view code, or data structures to pass to the templates) as so many of the other engines relied on.

I expanded my search outside of Ruby for the best html template technology I could find. After reviewing all the front runners I still didn’t find anything that quite met with my goals for developing with ruby and rails. I also didn’t find any technology that was close enough that I could adapt it. However I did come across features in a variety of systems that inspired me, and helped me shape the ideas that are presented here. A few of those systems were Tapestry, Zope/PHP TAL, Kwartz, Amrita 2, Liquid, and Web Objects.

After putting much thought into all the possible options I could not see extending an existing template engine to meet my needs. And since I wanted this engine to have all the power of ruby and rails, it seemed that I would be best served by developing a html template syntax that was a thin layer above ERb. That way it would be intuitive to use (not having to learn yet another syntax) yet very powerful. Once I was able to come up with the desired syntax and approach it became apparent that this would also be fairly straightforward to build.

I ran the concept by the guys at the St. Louis Ruby Group stlruby.org and they were excited about the project. With their help I was able to simply some of the confusing or complicated areas before beginning development. They also sparked some ideas about how to make this infinitely extensible such that developers could easily add their own attribute directives. This would give them the power to create custom extensions that would encapsulate some of their development work. This would serve a couple needs, it would not only make this engine extensible, it would also allow this engine to grow easily being composed of small pluggable attribute directives. Many thanks to the members of this group, I continue to enjoy discussing the power of Ruby and learning from each of them on a monthly basis.

While I am on the subject of thanks, I would like to thank my wife and daughter for their support as I took time away from them to work on this project and I want to thank God for bringing the right people into my life just when I needed them and for bringing me on this wonderful journey, I am so very blessed. May I be able to give back some of what has been given to me.

And one more mention of tremendous thanks to Deb Lewis, the other core developer on the team, she has spent countless hours reviewing, revising, and improving the codebase, configuration, and documentation. The project wouldn't be half of what it is today without all her help, inspiration, and hard work. I thoroughly enjoy working and debating the finer points of the project with her each step of the way.

So that’s the story, I hope that many of you will find MasterView to be a useful tool for your development. I am continuing to refine MasterView by using it daily for Genesis Ministry sites and all my web projects. I know that there is much more work needed in documentation, examples, test cases, additional directives, etc., so I would appreciate any feedback and ideas that you have. Thanks for taking the time to review MasterView!

Jeff Barczewski (jeff.barczewski (at) gmail (dot) com)