Why Wouldn't You Use Erector?

38 views
Skip to first unread message

Alex Chaffee

unread,
Oct 4, 2009, 12:56:02 AM10/4/09
to erector
Here's a draft of a blog post I want to make. Any additions or corrections or suggestions are more than welcome.

---

**Why Wouldn't You Use Erector?**

No, seriously. Why wouldn't you use Erector? Cause I think it's a pretty awesome view framework, but for some reason it hasn't caught fire yet. So if you think writing actual Ruby to emit HTML, with a clean, nestable syntax with full support for Ruby features like inheritance, delegation, and yield is neat, but there's something holding you back, then please let us know what it is. At best we can fix it, and at worst, at least we'll know why.

Here are some reasons I think you might not use Erector:

**You love angle brackets.** If this is the case then I can't help you. I don't think anybody can.

**You like typing every tag name twice.** Since Erector elements are Ruby statements, every open tag gets automatically closed.

**You like invalid HTML.** Since Erector elements are Ruby statements, every open tag gets automatically closed. (See how that works?)

**You always remember to call 'h'.** Rails 3.0 is going to HTML-escape all output by default. Erector's been doing this the whole time. Cause, you know, why wouldn't you?

**You like having to rewrite your code when you extract a partial, and then again when you extract a helper method.** In ERB, templates, partials, and helpers all have slightly (and annoyingly) different syntax for things like referring to variables and calling other code. Erector is all Ruby, so you can use your [favorite refactoring browser](http://www.jetbrains.com/ruby/), or just cut and paste, to move your code around. Check out this  [excerpt from Jeff Dean's RailsConf talk](http://www.youtube.com/watch?v=hTfCPkDV0Xo) to see this in action, or read [the slides from the whole talk on SlideShare](http://www.slideshare.net/alexchaffee/advanced-views-with-erector).

**You hate encapsulation.** You think that your views should have direct access to all the instance variables of your controller. Unless they're partials, in which case you [shouldn't](http://www.robertshowalter.com/articles/2007/07/24/dont-use-instance-variables-in-partials), even though you can although they might mean different things. Confused yet? So am I.

---

Okay, so those were sarcastic reasons. Here are some more possible reasons why you wouldn't use Erector. I suspect that these next ones hit closer to the mark. But I believe that they're all specious, if not downright false.

**Your site contains a whole lot of complex HTML and a few inserted Ruby variables.** OK, this makes sense. Erector's not great for static sites. But I've never personally worked on a web application where the code inside the views didn't quickly get complex enough to require codey things like loops and functions. And if you're writing code, then why not do it in a programming language?

**Your designers don't know Ruby.** I've heard this complaint a lot, but I have yet to meet this mythical designer who's smart enough to understand modern HTML, CSS, JavaScript, ERB, and partials, but is not smart enough to learn that "div 'foo', :class=>'bar'" outputs "<div class='bar'>foo</div>". On the contrary, I've worked with several designers who, after a few tutorial pairing sessions, were comfortable checking code in and out and editing Erector view code at will. Like any junior coder, they need to stay away from the tough stuff, but they're pretty good at knowing what they don't know and asking for help when they need it. (Which they would also do if working inside ERB.)

**View code needs to look as similar to HTML as possible.** Well, I hear this, but have you looked at HAML? That language is hella popular, and it doesn't look anything like HTML. Its structure is similar, in the abstract, but so's Erector's, and at least in Erector the method for emitting a div is called, you know, "div". And I don't want to turn this into a war between HAML and Erector -- I think HAML is gorgeous -- but HAML suffers from the same design flaw as every templating technology: views are not objects, and markup isn't code. After a certain point of complexity, HAML's elegance breaks down and you'd be better off doing loops and functions in code.

**You've already got a bunch of stuff in ERB and it'd take too long to convert it.** Yes, legacy code is a pain, but we have a command-line tool that converts ERB (or HTML) to Erector to make it a bit smoother. And you don't have to convert your whole app to Erector at once. Erector views can interoperate with Rails ERB or HAML.

**Erector's too slow.** Lies! Erector is faster than a greased rattlesnake going downhill. Check out [these benchmarking results](http://erector.rubyforge.org/faq.html#howfastiserectorcomparedtoerbhamletc ). Erector is about 2x as fast as ERB and 4x as fast as HAML under typical conditions.

**There's no documentation.** More lies! We have a whole bunch of documentation at <http://erector.rubyforge.org>, including a FAQ and a user guide.

**Rails has all these great helpers and I want to keep using them.** Okay, go right ahead! Erector's Rails integration allows you to call any helper, either directly through a proxy method, or indirectly through the helpers object. If you find a helper that doesn't work, let us know and we'll add it to the list of supported helpers. (We haven't done all of them yet because it's a pain in the neck to look at each function and figure out what its input and output semantics are. Does it return a string or emit directly onto the output stream? Does it take a block? An options hash? An html_options hash? Etc.) We're also slowly putting some Rails functionality into Erector, either in the base class or in custom widgets. If there's something you need, ask on the mailing list, or better yet, send us a patch.

**Its name is a dirty word.** I've heard this more from people who didn't grow up in the United States, where the [Erector Set](http://en.wikipedia.org/wiki/Erector_Set) was a popular toy among the 6-to-12-year-old DIY set in the 70s and 80s. (Apparently it was called [Meccano](http://en.wikipedia.org/wiki/Meccano) in the UK.)
Erector is a normal word, used all the time in the [news](http://tinyurl.com/yd55pal) and in [business names](http://google.com/search?q=steel+erector). And as the name of a view library it's evocative in a way that's relevant and interesting, in that it's a builder, and you build a view up out of parts.

But we have heard this complaint, and in sympathy, changed the name of the command-line tool (oh, sorry, guess I can't say "tool" either)-- uh, executable-- from "erect" to "erector" even though the former is a venerable English verb that's grammatically appropriate ("I asked him to erect the scaffolding."). If you introduce the library and your coworkers get all giggly then I think if you just say the name with a straight face and then roll your eyes and mock your bawdy buddies when they snicker then all will be well.

**You've never heard of it.** Help spread the word! Post a review on your blog! Ask your favorite app framework whether they support it! Post code samples in Erector and when people say "What's that?" then point them at <http://erector.rubyforge.org>! Give a talk at a meetup! Write your congressman and ask if she supports the Erector Mandate Bill of 2009! Buy [ad space on the moon](http://www.universetoday.com/2009/07/24/company-looks-to-etch-advertising-on-the-moon/)!

---

So, in conclusion, and despite my somewhat snarky tone throughout, I am honestly and desperately curious to know why the world has not yet beat a path to Erector's door. Anybody got any more ideas?

Grzegorz Junka

unread,
Oct 4, 2009, 4:17:11 PM10/4/09
to erector
Hi Alex,
I think Erector is great and I also have no idea why people wouldn't use
it. But maybe you should ask the opposite - how often Erector is being
used in real projects comparing to other view frameworks? I think Ruby
view frameworks are not being used very often in general. If there are
any known sites which use Erector then they should be listed on the
Erector website! Another issue is that Erector is, as far as I know, the
newest view framework among all the other best known. It is like with
PostgreSQL, which is better in many means than MySQL but people still
choose MySQL because other people already use it, there is more
books/articles on it, etc. However, the most important issue for
companies may be that Erector is still in its beta/development stage, as
indicated by its version. Maybe you just need to be patient and Erector
will stand up for itself when the time comes?
Thanks for your continuous support!
Greg

Chad Woolley

unread,
Oct 4, 2009, 11:35:16 PM10/4/09
to erector
On Sat, Oct 3, 2009 at 9:56 PM, Alex Chaffee <ale...@gmail.com> wrote:
> Here's a draft of a blog post I want to make. Any additions or corrections
> or suggestions are more than welcome.

The greatest fear I would have is maintainability.

There is a Rails project I recently tried to upgrade. The usage of
Markaby essentially killed the upgrade by burning up all of the
allocated time trying to fix and/or find a working version, because of
the horribly fragmented and confused state of Markaby. This made me
very sad and upset, not only because I looked bad by failing to finish
the upgrade, but also because I've got to either let this app languish
without an upgrade (which is causing much unrelated pain), or invest
the time to finish the upgrade (make Markaby work or rip it out).

So, even if Erector is the greatest thing since sliced bread under the
current and previous Rails versions, I'd very wary of using
non-standard shiny new technologies in an app, lest I doom the
inheritors of my app to a situation like I had with the Markaby
upgrade fiasco. Especially after Rails 3 hits.

In other words, I'm a minimalist, and I like standard (working!)
technologies, and don't get easily bent if I can't use shiny new
technologies when old ones work fine (albeit with some extra
unnecessary work). I'm perfectly fine with using ERB, because I'm
positive it is going to be well-maintained as Rails moves forward.
Especially after Rails 3 hits.

Anyway, that's a bit of an extreme straw man argument which I'm sure
you can easily immolate, Alex; but I'm just trying to help you out
with a POV from the devil's advocate. It is a valid concern.

-- Chad

P.S. By the way, have I ever mentioned how I hate for the reply-to not
being set to the list? I have, and I'll continue every time I have to
manually paste the list address to a reply. That is wrong, you should
fix it.

Steve Conover

unread,
Oct 5, 2009, 12:24:45 AM10/5/09
to thewoo...@gmail.com, erector
Yeah, the 50-million-erb-fans-can't-be-wrong FUD. I'm not saying that
what you're saying is untrue, but all you have to do is take action
and do something about it.

Btw how is that haml gets a pass these days?

Chad Woolley

unread,
Oct 5, 2009, 12:27:54 AM10/5/09
to Steve Conover, erector
On Sun, Oct 4, 2009 at 9:24 PM, Steve Conover <scon...@gmail.com> wrote:
> Yeah, the 50-million-erb-fans-can't-be-wrong FUD.  I'm not saying that
> what you're saying is untrue, but all you have to do is take action
> and do something about it.

This is much easier said than done on a low-budget maintenance
project, where the customer may freak over a day or two to upgrade,
much less a week of
patching-old-outdated-unmaintained-shit-to-work-just-so-you-can-continue-with-the-upgrade-to-fix-an-unrelated-problem.

I don't call it FUD, I call it reality on a maintenance project.

-- Chad

Brian Takita

unread,
Oct 5, 2009, 1:01:29 AM10/5/09
to thewoo...@gmail.com, Steve Conover, erector
On Sun, Oct 4, 2009 at 9:27 PM, Chad Woolley <thewoo...@gmail.com> wrote:
>
> On Sun, Oct 4, 2009 at 9:24 PM, Steve Conover <scon...@gmail.com> wrote:
>> Yeah, the 50-million-erb-fans-can't-be-wrong FUD.  I'm not saying that
>> what you're saying is untrue, but all you have to do is take action
>> and do something about it.
>
> This is much easier said than done on a low-budget maintenance
> project, where the customer may freak over a day or two to upgrade,
> much less a week of
> patching-old-outdated-unmaintained-shit-to-work-just-so-you-can-continue-with-the-upgrade-to-fix-an-unrelated-problem.
A motivation for making Erector is to make a more maintainable Markaby.
Also, you must consider Yehuda's efforts to make a solid Rails api for
supporting additional view frameworks.

Having a large community does diminish the likelihood of there being
issues with upgrades, since more people will be using the library. If
there is an issue, usually you can write an email to the project
maintainers.

Fortunately, Erector is an active project, unlike Markaby, it seems.

kristian

unread,
Oct 5, 2009, 1:19:16 AM10/5/09
to erector, thewoo...@gmail.com, Steve Conover
hi,

just to let you know: after two rails upgrade I was about to gave up
markaby and was pretty happy to find erector and ever since it went
smoothly with little hick ups here and there.

on top it I got object oriented framework which I really like, too.

and I am using it for to production site right now and recommend
erector whenever I can.

so far many thanx to the erector team for their work - it really help
my projects a lot !!!!

with regards
Kristian
--
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

_=_
q(-_-)p
'_) (_`
/__/ \
_(<_ / )_
(__\_\_|_/__)

Chad Woolley

unread,
Oct 5, 2009, 1:34:08 AM10/5/09
to Brian Takita, Steve Conover, erector
On Sun, Oct 4, 2009 at 10:01 PM, Brian Takita <brian....@gmail.com> wrote:
> A motivation for making Erector is to make a more maintainable Markaby.
> Also, you must consider Yehuda's efforts to make a solid Rails api for
> supporting additional view frameworks.

Yes, I await that glorious day, and I'll feel much more comfortable
when it is simply a matter of choosing a view framework which passes
everything in the rails API compatibility suite. Unfortunately, that
day has yet to come.

> Fortunately, Erector is an active project, unlike Markaby, it seems.

Markaby was active at one time. It still is actually -
coincidentally, I've been communicating these same concerns to one of
the guys maintaining Markaby. That still didn't change my situation,
and I believe it is primarily due to the lack of a plugin API, not the
skill of the maintainers or persistence/disappearance of the original
authors.

-- Chad

Brian Takita

unread,
Oct 5, 2009, 2:29:31 AM10/5/09
to Chad Woolley, Steve Conover, erector
On Sun, Oct 4, 2009 at 10:34 PM, Chad Woolley <thewoo...@gmail.com> wrote:
> On Sun, Oct 4, 2009 at 10:01 PM, Brian Takita <brian....@gmail.com> wrote:
>> A motivation for making Erector is to make a more maintainable Markaby.
>> Also, you must consider Yehuda's efforts to make a solid Rails api for
>> supporting additional view frameworks.
>
> Yes, I await that glorious day, and I'll feel much more comfortable
> when it is simply a matter of choosing a view framework which passes
> everything in the rails API compatibility suite.  Unfortunately, that
> day has yet to come.
Yehuda has assured us, when he came into Pivotal, that ActionPack's
API is going to be relatively stable. AFAIK, the api has not changed
much since 2.2.x.

>
>> Fortunately, Erector is an active project, unlike Markaby, it seems.
>
> Markaby was active at one time.  It still is actually -
> coincidentally, I've been communicating these same concerns to one of
> the guys maintaining Markaby.  That still didn't change my situation,
> and I believe it is primarily due to the lack of a plugin API, not the
> skill of the maintainers or persistence/disappearance of the original
> authors.
Yes, this is one of the issues with developing plugins with Rails is
their sometimes poor code quality, particularly non-existent APIs.
Unfortunately, it only hurts the Rails ecosystem, as more effort needs
to be spent on making/maintaining libraries that often increase
productivity. This makes any plugin suspect, yet somehow things seem
to work out, albeit painfully.

Erector's design attempts to minimize the risks by not using complex
logic #method_missing (as does Markaby) and instead, having the logic
be in separate "proxy" helper methods. There is also integration
testing.

Yes, there is certainly a risk for regressions. There is also a
corresponding risk that no-so-optimal libraries and abstractions
introduce to your project's design.
>
> -- Chad
>
Btw, I'm still interested in your Rails compatibility stuff. Are you
going to release it?

Thanks,
Brian

Chad Woolley

unread,
Oct 5, 2009, 2:35:53 AM10/5/09
to Brian Takita, erector
On Sun, Oct 4, 2009 at 11:29 PM, Brian Takita <brian....@gmail.com> wrote:
> Yehuda has assured us, when he came into Pivotal, that ActionPack's
> API is going to be relatively stable. AFAIK, the api has not changed
> much since 2.2.x.
>
> Erector's design attempts to minimize the risks by not using complex
> logic #method_missing (as does Markaby) and instead, having the logic
> be in separate "proxy" helper methods. There is also integration
> testing.
>
> Yes, there is certainly a risk for regressions. There is also a
> corresponding risk that no-so-optimal libraries and abstractions
> introduce to your project's design.

Hmm. You're convincing me :) Is there a Markaby-to-Erector converter?

> Btw, I'm still interested in your Rails compatibility stuff. Are you
> going to release it?

Not sure what you mean. You can drop me a line off-list...

-- Chad

Brian Takita

unread,
Oct 5, 2009, 2:46:57 AM10/5/09
to Chad Woolley, erector
On Sun, Oct 4, 2009 at 11:35 PM, Chad Woolley <thewoo...@gmail.com> wrote:
> On Sun, Oct 4, 2009 at 11:29 PM, Brian Takita <brian....@gmail.com> wrote:
>> Yehuda has assured us, when he came into Pivotal, that ActionPack's
>> API is going to be relatively stable. AFAIK, the api has not changed
>> much since 2.2.x.
>>
>> Erector's design attempts to minimize the risks by not using complex
>> logic #method_missing (as does Markaby) and instead, having the logic
>> be in separate "proxy" helper methods. There is also integration
>> testing.
>>
>> Yes, there is certainly a risk for regressions. There is also a
>> corresponding risk that no-so-optimal libraries and abstractions
>> introduce to your project's design.
>
> Hmm.  You're convincing me :)  Is there a Markaby-to-Erector converter?
Cool. Unfortunately, there is not a Markaby-to-Erector converter.

I'm working on an *.ert template, which is a lot like Markaby. I'm
using the templates in a side project and converting .mab templates to
.ert. The Rails helper support is also going to be better, since one
would can simply use `link_to` instead of `rawtext link_to` (`text
link_to` in the case of Markaby).
It will be in the next release.


>
>> Btw, I'm still interested in your Rails compatibility stuff. Are you
>> going to release it?
>
> Not sure what you mean.  You can drop me a line off-list...

Sure thing.
>
> -- Chad
>
-Brian

Jeff Dean

unread,
Oct 5, 2009, 12:35:03 PM10/5/09
to erector
Is erector currently being built against edge rails? The biggest pain
I felt with erector was having to make changes to erector after rails
was released. On the day that edge rails becomes real rails, erector
should just work, and that hasn't been the case for the last few big
rails updates.

On Oct 5, 2:46 am, Brian Takita <brian.tak...@gmail.com> wrote:
> On Sun, Oct 4, 2009 at 11:35 PM, Chad Woolley <thewoolley...@gmail.com> wrote:

Alex Chaffee

unread,
Oct 5, 2009, 12:59:48 PM10/5/09
to jd...@pivotallabs.com, erector
Brian wrote the code that runs tests against Rails so he'd know for sure, but AFAIK it checks out the latest stable Rails and runs some integration tests against that.

The advantage of this is that since Edge Rails is changing so much it doesn't force us to chase a moving target, and if Edge Rails does change in a non-backwards-compatible way we don't have to maintain two branches. It was a huge headache in the early days having multiple branches / subdirs to support different versions of Rails so we just decided to cut our losses and support latest stable only.

The disadvantage, as you said, is that there's a lag between new Rails and the new Erector that supports it.

Also, as Brian noticed over the weekend, it's possible for our Rails suite to pass and still miss some Rails regressions.

I think the right solution is to be more diligent and not try to run against Edge unless a release is imminent. 

Also, currently we have to manually increment the version of Rails that gets checked out; we could either always check out the latest stable, or put something in the developer guide to remind people to do it more quickly. I personally have been the most active on the Erector codebase but I don't use Rails so I missed the 2.3.4 upgrade. When Brian upgraded to 2.3.4, I found and fixed some failing tests, and Brian has apparently found a few more bugs.

Alex Chaffee

unread,
Oct 5, 2009, 1:03:03 PM10/5/09
to xg...@poczta.onet.pl, erector
On Sun, Oct 4, 2009 at 1:17 PM, Grzegorz Junka <xg...@poczta.onet.pl> wrote:

Hi Alex,
I think Erector is great and I also have no idea why people wouldn't use
it. But maybe you should ask the opposite - how often Erector is being
used in real projects comparing to other view frameworks?

HAML is quite popular. And they're both about the same age (2-3 years). 

> Maybe you just need to be patient and Erector
will stand up for itself when the time comes?

You're right that libraries need time to catch on, but I'm trying to prime the pump. Cause Erector's awesome :-)

Alex Chaffee

unread,
Oct 5, 2009, 1:06:55 PM10/5/09
to thewoo...@gmail.com, erector
 
P.S. By the way, have I ever mentioned how I hate for the reply-to not
being set to the list?  I have, and I'll continue every time I have to
manually paste the list address to a reply.  That is wrong, you should
fix it.



I subscribe to the SF Ruby Meetup list and at least once a week someone accidentally posts a private response to 1600 people because they're used to "[R]eply" going to one and "Reply [A]ll" going to many.

You don't have to manually paste anything; just reply to all. It's "A" in GMail. Modern mail clients don't receive duplicates, and don't display them when they do.

 - A

Chad Woolley

unread,
Oct 5, 2009, 1:07:18 PM10/5/09
to ale...@gmail.com, jd...@pivotallabs.com, erector
On Mon, Oct 5, 2009 at 9:59 AM, Alex Chaffee <ale...@gmail.com> wrote:
> The advantage of this is that since Edge Rails is changing so much it
> doesn't force us to chase a moving target, and if Edge Rails does change in
> a non-backwards-compatible way we don't have to maintain two branches. It
> was a huge headache in the early days having multiple branches / subdirs to
> support different versions of Rails so we just decided to cut our losses and
> support latest stable only.
> I think the right solution is to be more diligent and not try to run against
> Edge unless a release is imminent.

This attitude sort of contradicts Brian's (Yehuda's) assertion that
the API is stable and shouldn't be changing that much.

Why don't you run CI against the latest edge rails? If the API is
truly getting stable, then you should be able to do version checks to
support the 2.3 branch and the master branch. If that is too hard to
do, then perhaps my fears of forward-compatibility risk are not
entirely unfounded :)

-- Chad

Chad Woolley

unread,
Oct 5, 2009, 1:13:51 PM10/5/09
to Alex Chaffee, erector
On Mon, Oct 5, 2009 at 10:06 AM, Alex Chaffee <ale...@gmail.com> wrote:
> I subscribe to the SF Ruby Meetup list and at least once a week someone
> accidentally posts a private response to 1600 people because they're used to
> "[R]eply" going to one and "Reply [A]ll" going to many.

I solidly prefer that risk over people wanting to reply to the list,
but instead unknowingly sending a private message because they hit
reply instead of reply all (as I've caught myself almost doing three
times in this thread). Most mailing lists do not work the way you are
want, Chafee, they are set as reply-to-list, so your setting violates
the principle of least surprise.

Also:
* Even on the meetup list, people learn after a time or two
* There are not 1600 people (mostly recruiters anyway?) on this list
* The level of technical and email-client ability on this list is
hopefully higher than the SF Ruby meetup

Alex Chaffee

unread,
Oct 5, 2009, 1:15:09 PM10/5/09
to Chad Woolley, jd...@pivotallabs.com, erector
> I think the right solution is to be more diligent and not try to run against
> Edge unless a release is imminent.

This attitude sort of contradicts Brian's (Yehuda's) assertion that
the API is stable and shouldn't be changing that much.


It's *going* to be stable, right? Is it yet? I'm still back in "once burned, twice shy" and "seeing is believing" land with Rails. (Like you are with Markaby.)
 
Why don't you run CI against the latest edge rails?  If the API is
truly getting stable, then you should be able to do version checks to
support the 2.3 branch and the master branch.  If that is too hard to
do, then perhaps my fears of forward-compatibility risk are not
entirely unfounded :)

That's a fine idea. Maybe some combination of you, me, and Brian could work on getting the Rails version to be configurable in different CI builds, and then put up a CI instance for that.

 - A

Alex Chaffee

unread,
Oct 5, 2009, 1:16:23 PM10/5/09
to thewoo...@gmail.com, Brian Takita, Steve Conover, erector
> Fortunately, Erector is an active project, unlike Markaby, it seems.

Markaby was active at one time.  It still is actually -
coincidentally, I've been communicating these same concerns to one of
the guys maintaining Markaby.  That still didn't change my situation,
and I believe it is primarily due to the lack of a plugin API, not the
skill of the maintainers or persistence/disappearance of the original
authors.


The main design goal of Erector was to be a better Markaby. We have steadily removed magic(*). API changes have been documented and the biggest included an upgrade guide (**). We run integration tests against Rails at will. We're doing what we can. We're totally on your side here! :-)



Chad Woolley

unread,
Oct 5, 2009, 1:22:43 PM10/5/09
to Alex Chaffee, jd...@pivotallabs.com, erector
On Mon, Oct 5, 2009 at 10:15 AM, Alex Chaffee <ale...@gmail.com> wrote:
> That's a fine idea. Maybe some combination of you, me, and Brian could work
> on getting the Rails version to be configurable in different CI builds, and
> then put up a CI instance for that.

You get the master-branch build working, and I'll set up a new project
for it on http://ci.pivotallabs.com/

Alex Chaffee

unread,
Oct 5, 2009, 2:08:44 PM10/5/09
to Chad Woolley, jd...@pivotallabs.com, erector
The master branch has been green for months. The CI install seems to
have been frozen since June with

"
/home/pivotal/.cruise/projects/Erector/work pivotal$ git fetch origin
fatal: read error (Connection reset by peer)
"

I restarted it and now it's failing because nokogiri needs to be
native-compiled on the CI box. Can you sudo gem install that sucker?

Chad Woolley

unread,
Oct 5, 2009, 2:35:10 PM10/5/09
to Alex Chaffee, jd...@pivotallabs.com, erector
On Mon, Oct 5, 2009 at 11:08 AM, Alex Chaffee <ale...@gmail.com> wrote:
> The master branch has been green for months. The CI install seems to
> have been frozen since June with
>
> "
> /home/pivotal/.cruise/projects/Erector/work pivotal$ git fetch origin
> fatal: read error (Connection reset by peer)
> "

Yes, I am trying to fix that bug as we speak, but it is a hard one
(MRI 1.8.6 can't timeout IO blocking threads). Unfortunately, it is
tricky. Check the ccrb dev list and lighthouse for more info.

>
> I restarted it and now it's failing because nokogiri needs to be
> native-compiled on the CI box. Can you sudo gem install that sucker?

You should be able to do it yourself with GemInstaller as part of your
build. Geminstaller runs under nopasswd sudoers. Or even better, try
out Bundler...

Brian Takita

unread,
Oct 5, 2009, 4:27:34 PM10/5/09
to ale...@gmail.com, Yehuda Katz, Chad Woolley, jd...@pivotallabs.com, erector
On Mon, Oct 5, 2009 at 10:15 AM, Alex Chaffee <ale...@gmail.com> wrote:
>> > I think the right solution is to be more diligent and not try to run
>> > against
>> > Edge unless a release is imminent.
>>
>> This attitude sort of contradicts Brian's (Yehuda's) assertion that
>> the API is stable and shouldn't be changing that much.
>>
>
> It's *going* to be stable, right? Is it yet? I'm still back in "once burned,
> twice shy" and "seeing is believing" land with Rails. (Like you are with
> Markaby.)
I'm copying Yehuda on this.

Yehuda came to Pivotal to discuss Desert and our other Open source efforts.
Yehuda mentioned that the ActionView api was one the first things he
worked on and is relatively stable.

Yehuda, please correct any misunderstandings on my part.

To provide context, we are trying to integrate Erector with Rails.
There has been a history of integration issues due to the
monkey-patching and the changing internal api with templates and
helpers.

FYI, Erector is a html builder framework, similar to Markaby and Tagz.
The big difference is Erector uses widget objects under the hood.

Thank you,
Brian

Yehuda Katz

unread,
Oct 5, 2009, 4:34:14 PM10/5/09
to Brian Takita, ale...@gmail.com, Chad Woolley, jd...@pivotallabs.com, erector
The template handling API is pretty rock solid at this point. I don't anticipate any future changes. The Resolver API is also pretty solid. The only caveat I'd have is that we might be forced to change things in response to feedback from you guys. Which is a good reason to try and make it work on edge.

-- Yehuda
--
Yehuda Katz
Developer | Engine Yard
(ph) 718.877.1325

Alex Chaffee

unread,
Oct 5, 2009, 4:45:08 PM10/5/09
to Brian Takita, Yehuda Katz, Chad Woolley, jd...@pivotallabs.com, erector
Sounds pretty persuasive. Brian, if you want a pair for this, would you like to come to my place one evening or weekend soon?

Brian Takita

unread,
Oct 5, 2009, 6:16:24 PM10/5/09
to Alex Chaffee, Yehuda Katz, Chad Woolley, jd...@pivotallabs.com, erector
On Mon, Oct 5, 2009 at 1:45 PM, Alex Chaffee <ale...@gmail.com> wrote:
> Sounds pretty persuasive. Brian, if you want a pair for this, would you like
> to come to my place one evening or weekend soon?
Yes I would. I'm already away from home too many days this week. Maybe
next week? I may be able to do this weekend, but I need to check with
my better half. :-)

Rick Moynihan

unread,
Oct 5, 2009, 7:05:38 PM10/5/09
to scon...@gmail.com, thewoo...@gmail.com, erector
2009/10/5 Steve Conover <scon...@gmail.com>:

>
> Yeah, the 50-million-erb-fans-can't-be-wrong FUD.  I'm not saying that
> what you're saying is untrue, but all you have to do is take action
> and do something about it.
>
> Btw how is that haml gets a pass these days?

Just thought I'd offer my 2 cents worth on this debate.

For the record I love Erector, and have started using it on one
project. I've always had a penchant for staying within the language
and several years ago was quite fond of markaby (though never used it
in production - but did write some toy projects with it).

Anyway, the only fear I have when choosing something like Erector is
that I perceive it being a barrier for whenever I might want to
involve a designer in my work. I know they're *very* familiar with
HTML+CSS etc, but worry that their preferred tools won't support
Erector / ruby code... i.e. they'll lack basic editor support etc...

I'm sure most good designers won't be impaired too badly by this, but
I'd expect some resistance to it, where as I think with erb they'll be
more familiar. Obviously the erector tools for converting HTML to
erector etc... can dramatically ease this workflow, but I still think
it's a valid concern (even for those of us who are enlightened)

R.

jonty

unread,
Oct 6, 2009, 5:38:23 AM10/6/09
to thewoo...@gmail.com, Alex Chaffee, erector
I agree with you Chad.

I also have been caught by this as you are no doubt aware Alex as you
got my comments privately instead of too the list!

I like to simply 'reply' to continue the thread and I can see the
posters email if I want to continue privately.

However I will look at the 'to' section of my email client in the future
to be sure where its going!

Any chance of a change?

jonty

Alex Chaffee

unread,
Oct 6, 2009, 12:46:44 PM10/6/09
to jont...@btinternet.com, thewoo...@gmail.com, erector
This is a religious issue, with strong feelings on both sides. And as
long as I hold the keys to this list we're playing by my rules!!!

That said, two points in reply:

I consider the risk of inadvertently sharing private communcation to
be much greater than the opposite.

And it is so much more of a pain to copy and paste an email address
buried in the headers than to hit "a".

Changing subject line so agnostics can mute the thread :-)

Sent from my iPhone

On Oct 6, 2009, at 2:38 AM, jonty <jont...@btinternet.com> wrote:n

Chad Woolley

unread,
Oct 6, 2009, 1:02:22 PM10/6/09
to Alex Chaffee, jont...@btinternet.com, erector
On Tue, Oct 6, 2009 at 9:46 AM, Alex Chaffee <ale...@gmail.com> wrote:
> This is a religious issue, with strong feelings on both sides. And as long
> as I hold the keys to this list we're playing by my rules!!!
>
> That said, two points in reply:
>
> I consider the risk of inadvertently sharing private communcation to be much
> greater than the opposite.

How often do you include private information when replying to a
*public* thread on a *public* mailing list? For me, the answer is
almost never, and if I do, then I double check my recipients (as I do
on all sensitive emails).

The purpose of a public, technical mailing list is to *publicly* share
information, for everyone's benefit. The common (and should thus be
the default) behavior is to engage in a group discussion. People who
do not want to engage in or read public discussions should subscribe
as digest, mute uninteresting threads, archive and read later, or
unsubscribe.

Sorry, not buyin' this one...

>
> And it is so much more of a pain to copy and paste an email address buried
> in the headers than to hit "a".

I don't know what you are talking about. My default behavior is to
reply, NOT to reply all. Every other mailing list I am on operates
this way, so it is a habit. This is also the correct default for
personal emails, where I DO want to avoid copying cc'd people on
personal email.

So, every time I reply to you on this list, I do the following:

* hit reply
* start typing
* realize I'm only replying to you.
* Copy the half-composed reply
* discard the message
* hit reply all
* paste my reply
* finish.

THAT is a pain...

Go with the flow man, go with the flow...

> Changing subject line so agnostics can mute the thread :-)

Very good list etiquette :)

> Sent from my iPhone

How the hell can you type so much on those tiny keys??? And how can
you live with the default Mail client? Nevermind, that's another
thread :)

-- Chad

P.S. Just noticed, I hit reply instead of reply all. AGAIN.

Alex Chaffee

unread,
Oct 6, 2009, 1:49:51 PM10/6/09
to Chad Woolley, jont...@btinternet.com, erector
>> I consider the risk of inadvertently sharing private communcation to be much
>> greater than the opposite.
>
> How often do you include private information when replying to a
> *public* thread on a *public* mailing list?  For me, the answer is
> almost never, and if I do, then I double check my recipients (as I do
> on all sensitive emails).

When I want to say something personal, like "what is this guy
smokin'?!?!?" That's why the risk is high... private usually means
sensitive, especially when on a list.

And double-checking works until it doesn't.

> * hit reply
> * start typing
> * realize I'm only replying to you.
> * Copy the half-composed reply
> * discard the message
> * hit reply all
> * paste my reply
> * finish.

Are you using GMail? You can just click "Reply To All" and it copies
the message over for you (actually it's just changing the headers). Or
hit "tab" to deselect the text area and then hit "a". Then hit "tab-r"
and then "tab-a" again to see how smooth it is.

> Go with the flow man, go with the flow...

Hey, I'm *Mister* Flow...

>> Changing subject line so agnostics can mute the thread :-)
>
> Very good list etiquette :)

That's what Mister Flow is all about!

- A

Jim Kingdon

unread,
Oct 6, 2009, 11:48:50 PM10/6/09
to ale...@gmail.com, erector
> **You always remember to call 'h'.** Rails 3.0 is going to HTML-escape all
> output by default. Erector's been doing this the whole time. Cause, you
> know, why wouldn't you?

Oh, sure, make me feel like an old fogey just because I can remember a
time before "the whole time" started ;-).

> So, in conclusion, and despite my somewhat snarky tone throughout, I am
> honestly and desperately curious to know why the world has not yet beat a
> path to Erector's door. Anybody got any more ideas?

I think the explanation lies in the reasons you list and obvious ones like
"ERB had a head start".

My own erector-reluctance (to the extent that I have any) is a subtle one,
and might be hard for anyone with less skill than Martin Fowler to
explain, but I'll try:

Erector encourages excessively clever views. Because views are code,
application of principles such as Don't Repeat Yourself, your favorite
Design Anti-Pattern (or pattern which would be good elsewhere but is
misapplied), etc, can turn views into overly complex spaghetti when the
real solution to views which seem to require complex machinery to output
is really to simplify the generated HTML so much that the machinery just
seems superfluous (insert pitch for web standards, CSS, and other
"newfangled" thoughts on clean HTML).

And to answer my own objection: Avoid this nightmare by being judicious.
Don't break out the views into a lot of methods, subclasses, and composed
classes just because you can - do those things if they solve a real
problem which you have.


Rick Moynihan

unread,
Oct 7, 2009, 5:57:07 AM10/7/09
to kin...@panix.com, ale...@gmail.com, erector
2009/10/7 Jim Kingdon <kin...@panix.com>:

>
>> **You always remember to call 'h'.** Rails 3.0 is going to HTML-escape all
>> output by default. Erector's been doing this the whole time. Cause, you
>> know, why wouldn't you?
>
> Oh, sure, make me feel like an old fogey just because I can remember a
> time before "the whole time" started ;-).
>
>> So, in conclusion, and despite my somewhat snarky tone throughout, I am
>> honestly and desperately curious to know why the world has not yet beat a
>> path to Erector's door. Anybody got any more ideas?
>
> I think the explanation lies in the reasons you list and obvious ones like
> "ERB had a head start".
>
> My own erector-reluctance (to the extent that I have any) is a subtle one,
> and might be hard for anyone with less skill than Martin Fowler to
> explain, but I'll try:
>
> Erector encourages excessively clever views.  Because views are code,
> application of principles such as Don't Repeat Yourself, your favorite
> Design Anti-Pattern (or pattern which would be good elsewhere but is
> misapplied), etc, can turn views into overly complex spaghetti when the
> real solution to views which seem to require complex machinery to output
> is really to simplify the generated HTML so much that the machinery just
> seems superfluous (insert pitch for web standards, CSS, and other
> "newfangled" thoughts on clean HTML).

So the argument here is essentially:

"Using plain HTML, CSS and crappy-ERB leads to better code because its
significant shortcomings force you to focus on creating clean HTML."

Note, I'm not advocating the view (as I don't think you were)...
Rather I'm just trying to summarise your point. Is the moral of this
story: "Ensure the HTML/CSS output is clean and simple before you try
and hide it's complexity with Erector" ?

R.

Jim Kingdon

unread,
Oct 7, 2009, 9:28:29 PM10/7/09
to Rick Moynihan, kin...@panix.com, ale...@gmail.com, erector
> "Ensure the HTML/CSS output is clean and simple before you try
> and hide it's complexity with Erector" ?

Yes (well, HTML anyway. Avoiding CSS spaghetti is a somewhat different
problem).


Alex Chaffee

unread,
Oct 8, 2009, 1:43:03 PM10/8/09
to Jim Kingdon, Rick Moynihan, erector

An unexpected return to the original topic! New paragraph:

**You like putting code for one component in three separate files.**
Erector's new "externals" feature allows you to put all the code --
HTML, CSS, and JavaScript -- inside a single Ruby class. The CSS and
JavaScript then get output inside the HEAD, once per HTML page, while
the HTML gets rendered in the BODY as usual, as many times as
necessary. This follows the OO paradigm of cohesion, otherwise known
as "put similar stuff together," which is the complement of loose
coupling, which means, "keep different stuff apart."

I also intend to add "less" and "sass" commands pretty soon.

- A

John Firebaugh

unread,
Oct 15, 2009, 8:57:00 PM10/15/09
to erector
My team has been considering using erector. It looks ideally suited
for one of our major goals -- componentization of common template
elements. But we're facing a couple of roadblocks. And since you
asked, here they are:

- Rails integration appears to be broken at the moment -- see
http://groups.google.com/group/erector/browse_thread/thread/486e0f1a013889b1
- Rails integration is incomplete. We don't care about support for
partials, layouts, or custom helpers -- if we're going to use erector,
we'll go whole hog and replace them with widgets. But we do need
complete support for rails's built in helper methods. IMO, the way
erector is currently approaching this, with either a custom wrapper
function for every helper method or the required use of the "helpers"
proxy, is the wrong approach. I should just be able to call any helper
directly, as I would in erb, haml, or most any other template
language. (Maybe rails's new on-by-default XSS protection would make
this easier to implement?)

There's also room for improvement in the documentation and specs. But
those are secondary -- and areas we could certainly contribute to, if
the rails integration issues were addressed.

John

Alex Chaffee

unread,
Oct 16, 2009, 1:28:57 PM10/16/09
to john.fi...@gmail.com, erector
On Thu, Oct 15, 2009 at 5:57 PM, John Firebaugh
<john.fi...@gmail.com> wrote:
>
> My team has been considering using erector. It looks ideally suited
> for one of our major goals -- componentization of common template
> elements. But we're facing a couple of roadblocks. And since you
> asked, here they are:

Thanks!

> - Rails integration appears to be broken at the moment -- see
> http://groups.google.com/group/erector/browse_thread/thread/486e0f1a013889b1

Brian and I will look at this when/if we get together... Brian, how's
your weekend look? I could even come out to the dreaded East Bay if
you like...

> - Rails integration is incomplete. We don't care about support for
> partials, layouts, or custom helpers -- if we're going to use erector,
> we'll go whole hog and replace them with widgets. But we do need
> complete support for rails's built in helper methods. IMO, the way
> erector is currently approaching this, with either a custom wrapper
> function for every helper method or the required use of the "helpers"
> proxy, is the wrong approach. I should just be able to call any helper
> directly, as I would in erb, haml, or most any other template
> language.

Totally agree that you should be able to call any helper, but the
inconsistency of the Rails API makes this difficult. We haven't done
all of them yet because it's a pain in the neck to look at each
function and figure out what its input and output semantics are. Does
it return a string or emit directly onto the output stream? Does it
take a block? An options hash? An html_options hash? Etc... Given that
one of Erector's strengths is its *consistent* API (most methods emit
directly onto the output stream), it's hard to mesh gears with an
inconsistent one.

It might help if you identify the top 10 missing helpers. I started a
spreadsheet at Google Docs to help organize this effort; if you can
give feedback on the priorities that'd be great.
http://spreadsheets.google.com/pub?key=tgDgCnc3LyZ2Z-wQgAEDdeQ&output=html
(Ask me for an invite if you want to edit it.)

> (Maybe rails's new on-by-default XSS protection would make
> this easier to implement?)

Sadly, no. We've been escaping HTML by default since pre-version 0.1.

>
> There's also room for improvement in the documentation and specs. But
> those are secondary -- and areas we could certainly contribute to, if
> the rails integration issues were addressed.

Looking forward to the day! :-)

- A

John Firebaugh

unread,
Oct 16, 2009, 2:37:16 PM10/16/09
to Alex Chaffee, erector
On Fri, Oct 16, 2009 at 10:28 AM, Alex Chaffee <ale...@gmail.com> wrote:
Totally agree that you should be able to call any helper, but the
inconsistency of the Rails API makes this difficult. We haven't done
all of them yet because it's a pain in the neck to look at each
function and figure out what its input and output semantics are. Does
it return a string or emit directly onto the output stream? Does it
take a block? An options hash? An html_options hash? Etc... Given that
one of Erector's strengths is its *consistent* API (most methods emit
directly onto the output stream), it's hard to mesh gears with an
inconsistent one.

It might help if you identify the top 10 missing helpers. I started a
spreadsheet at Google Docs to help organize this effort; if you can
give feedback on the priorities that'd be great.
http://spreadsheets.google.com/pub?key=tgDgCnc3LyZ2Z-wQgAEDdeQ&output=html
(Ask me for an invite if you want to edit it.)

> (Maybe rails's new on-by-default XSS protection would make
> this easier to implement?)

Sadly, no. We've been escaping HTML by default since pre-version 0.1.

Sure. What I'm getting at though is that it may free erector from the need to write a wrapper for every individual helper. If we don't have to write a wrapper, we don't need to care about the inputs to the helper. It can take a block, options hash, whatever, erector wouldn't care. And the helpers now take care of escaping input when necessary, so erector no longer needs a wrapper to do that before passing it through to the helper. All that's left is the output. If the output is a string, there's now a way to detect if it's HTML safe or needs escaping. If it's emitted to the output stream, we can assume it was already escaped.

The "wrap every helper method" approach just doesn't seem like it should be necessary. Or am I missing something?

Alex Chaffee

unread,
Oct 19, 2009, 7:36:14 AM10/19/09
to John Firebaugh, erector
> Sure. What I'm getting at though is that it may free erector from the need
> to write a wrapper for every individual helper. If we don't have to write a
> wrapper, we don't need to care about the inputs to the helper. It can take a
> block, options hash, whatever, erector wouldn't care. And the helpers now
> take care of escaping input when necessary, so erector no longer needs a
> wrapper to do that before passing it through to the helper. All that's left
> is the output. If the output is a string, there's now a way to detect if
> it's HTML safe or needs escaping. If it's emitted to the output stream, we
> can assume it was already escaped.
> The "wrap every helper method" approach just doesn't seem like it should be
> necessary. Or am I missing something?

Maybe... or maybe I am!

The reason for wrapping has to do with escaping, but that's not the
only reason. We also wrap 'manually' because we weren't smart enough
to think of a way to automatically detect whether the wrapped method
returns a string or emits to the output stream. I suppose having said
it that way, I can now imagine checking the length of the output
buffer before and after, or something like that...

However, even that's oversimplifying it. Check out the source for
rails_helpers.rb:
http://github.com/pivotal/erector/blob/master/lib/erector/rails/extensions/rails_widget/rails_helpers.rb
There are four separate semantics for helpers we have to deal with --
escaped, raw, captured with concat, and captured without concat. Can
we detect all four?

- A

kristian

unread,
Oct 19, 2009, 8:10:55 AM10/19/09
to ale...@gmail.com, John Firebaugh, erector
I am sure what I did is over simplified but until now it worked very
well for me:

# render custom helper methods otherwise delegate to original
# method_missing
def method_missing_new(sym, *args, &block)
if helpers.respond_to?(sym, true)
r = @helpers.send(sym, *args, &block)
puts "helper #{sym} called"
if r.respond_to? :to_str
text raw(r.to_str)
else
r
end
else
method_missing_old(sym, *args, &block)
end
end

alias method_missing_old method_missing
alias method_missing method_missing_new

that was/is my usual patch on the widget class (but the erector
versions I am using a bit outdated by now !!)

with regards
Kristian
--
Kristian Meier + Saumya Sharma + Sanuka Meier
Vadakkethu House,
Edayanmula West PO - 689532,
Pathanamthitta District, Kerala, INDIA

tel: +91 468 2319577

protect your privacy while searching the net: www.ixquick.com

_=_
q(-_-)p
'_) (_`
/__/ \
_(<_ / )_
(__\_\_|_/__)

Harry

unread,
Oct 25, 2009, 9:12:20 AM10/25/09
to erector
again ,about the haml

.xyz to <div class="xyz"> grammar

this sometimes make it very straight forword to design the view
especialy when you combine it with blueprint css framework ,it's like
drawing on canvas . very useful feature . please include it . when you
want more poeple to use it ,you can't just think like an programmer,
think from those UI guy's view maybe helpful . UI guys will still
vomit when they have to write

div :class=>"xyz"

if possible , if Erector can be down-compatible to Haml ,then I can't
see anyreason people wont use it .

Harry

unread,
Oct 25, 2009, 8:49:38 AM10/25/09
to erector
Hi this is an awesome framework , but I would like it better if the
syntax are more clean like haml do , like this:

div :class => "xyz"

in haml ,this could be:

.xyz
of course in haml it can also be written as : .div{:class=> "xyz"}
but ,is there any possible to wite it as .xyz in erector?

Alex Chaffee

unread,
Oct 25, 2009, 12:05:30 PM10/25/09
to blogd...@gmail.com, erector

We can't write as plain ".xyz" cause there's no method there.

We could possibly extend the API to allow "div.xyz" but that leads to
some complications (see
http://www.pivotaltracker.com/story/show/177031 ) and so far you're
the first to request it in over a year. But it might be worth looking
into again. I agree that anything to make the Erector API more concise
and accessible is a good thing and should be considered.

- A

Brian Takita

unread,
Oct 25, 2009, 7:56:48 PM10/25/09
to ale...@gmail.com, john.fi...@gmail.com, erector
On Fri, Oct 16, 2009 at 10:28 AM, Alex Chaffee <ale...@gmail.com> wrote:
>
> On Thu, Oct 15, 2009 at 5:57 PM, John Firebaugh
> <john.fi...@gmail.com> wrote:
>>
>> My team has been considering using erector. It looks ideally suited
>> for one of our major goals -- componentization of common template
>> elements. But we're facing a couple of roadblocks. And since you
>> asked, here they are:
>
> Thanks!
>
>> - Rails integration appears to be broken at the moment -- see
>> http://groups.google.com/group/erector/browse_thread/thread/486e0f1a013889b1
>
> Brian and I will look at this when/if we get together... Brian, how's
> your weekend look? I could even come out to the dreaded East Bay if
> you like...
Hey Alex,

This weekend was not very good for me. Sorry. I can meet any time
after Monday, including next weekend.
It looks like there will some grunt work in getting all of the helpers
supported.

Thanks,
- Brian

Harry

unread,
Oct 26, 2009, 12:50:58 AM10/26/09
to erector
Hi ,thanks for the reply

:what I mean is not strictly a grammar like .xyz, I might mean how to
draw an graph on the webpage using the most straightforward and
concise gramar when combine with the populor grid-base css framework.
like in haml:
.span-24
.span-3
.span-18
.span- 3.last
can finish all the work to layout an 3 colums webpage when using
blueprint-css.this is the most concise expression I've ever seen.

can something like this possible in erector?:
#span-24
#span-3
#span-18
#span- 3#last
or %span-24 something.

div is the most used tag in an page ,so if some short cut to these
expression will be great help.

On Oct 26, 3:05 am, Alex Chaffee <ale...@gmail.com> wrote:
> On Sun, Oct 25, 2009 at 5:49 AM, Harry <blogdri...@gmail.com> wrote:
>
> > Hi this is an awesome framework , but I would like it better if the
> > syntax are more clean like haml do , like this:
>
> > div :class => "xyz"
>
> > in haml ,this could be:
>
> > .xyz
> > of course in haml it can also be written as : .div{:class=> "xyz"}
> > but ,is there any possible to wite it as .xyz in erector?
>
> We can't write as plain ".xyz" cause there's no method there.
>
> We could possibly extend the API to allow "div.xyz" but that leads to
> some complications (seehttp://www.pivotaltracker.com/story/show/177031) and so far you're
Reply all
Reply to author
Forward
0 new messages