Erector - Faq

• What is Erector?
• Where are the docs?
• Why use Erector?
• Where are some examples?
• How does Erector stack up against Markaby?
• How does Erector stack up against HAML?
• How do I use layouts?

What is Erector?

Erector is a Builder-like view framework, inspired by Markaby but overcoming some of its flaws. In Erector all views are objects, not template files, which allows the full power of object-oriented programming (inheritance, modular decomposition, encapsulation) in views.

Where are the docs?

See the rdoc for the Erector::Widget class to learn how to make your own widgets, and visit the project site at http://erector.rubyforge.org for more documentation, especially the user guide.

Why use Erector?

• Markaby-style DOM builder domain language
• Your views are real classes, written in a real language, allowing
  • Functional decomposition
  • Inheritance
  • Composition, not partials
  • Well-defined semantics for variables, loops, blocks
  • Dependency injection via constructor params
• As little magic as possible while maintaining Rails compatibility
• yield works again (Markaby broke it)
• Very testable
• form_for ERB code is craaaaazy (not to mention the quagmire of options vs. htmloptions)
• Output is streamed, improving performance over string copy

Where are some examples?

This very web site you're reading right now is built with Erector, using the erect tool. See the svn repository for source code.

We also have several examples checked in to the repository at http://erector.rubyforge.org/svn/trunk/examples.

Currently there are no open-source projects built with Erector so we can't show you working source code for a full Erector webapp.

How does Erector stack up against Markaby?

We loved Markaby when we first saw it, since it transformed the gnarliness of Rails' ERB views into a clean, functional programming lanugage where views are primarily code with ways to emit HTML, rather than HTML with ways to hack in code. However, we soon realized Markaby had two main flaws:

1. It didn't go quite far enough down the OO road -- Markaby views are still fragments, not classes
2. Its use of instance_eval and capture, as well as a view's functional-but-not-quite-an-object nature, led to too much magic and made it very difficult to debug

Erector was conceived as a natural evolution of Markaby, but overcoming these two flaws. We think Erector can do pretty much everything Markaby can; if you find a counterexample, please let us know on the erector-devel mailing list.

How does Erector stack up against HAML?

HAML is beautiful. But it suffers from the same design flaw (or, some would say, advantage) as every templating technology: views are not objects, and markup isn't code. But views want to do codey things like loops and variables and modular decomposition and inheritance, and every effort to wedge control logic into markup ends up smelling like a hack. There's always going to be some algorithmic idiom that's awkward in a template language. We figure, why deny it? Code is code. Embrace your true nature! Lick your screen and taste the code!

How do I use layouts?

Rails has a concept of layouts, which are essentially skeletons for a page, which get fleshed out by views. This is a powerful mechanism for rendering web pages; however, the mechanism Rails uses (via content_for and yield) is fundamentally incompatible with Erector's "just call render" design.

We recommend a slightly different approach, known officially as the Template Method Design Pattern: define a parent class (e.g. Page) and have your view widgets extend this class rather than directly extending Erector::Widget. The parent class implements render, and calls down to the child class to render sections or acquire information that's specific to that view.

For an example with source code, see the user guide.