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.
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
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
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
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
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
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?
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.
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
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
> I think the right solution is to be more diligent and not try to run againstThis attitude sort of contradicts Brian's (Yehuda's) assertion that
> Edge unless a release is imminent.
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 :)
> 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.
You get the master-branch build working, and I'll set up a new project
for it on http://ci.pivotallabs.com/
"
/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?
---
Alex Chaffee - al...@cohuman.com - http://alexch.github.com
Stalk me: http://friendfeed.com/alexch | http://twitter.com/alexch |
http://alexch.tumblr.com
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...
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.
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
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.
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
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.
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.
Yes (well, HTML anyway. Avoiding CSS spaghetti is a somewhat different
problem).
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
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
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.)
Sadly, no. We've been escaping HTML by default since pre-version 0.1.
> (Maybe rails's new on-by-default XSS protection would make
> this easier to implement?)
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
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