Markaby, ERB, and the rails lingua franca

One of the tenets of rails seems to be abstracting most of the cruft of web development (SQL, javascript) into pure, elegant ruby (ActiveRecord, RJS). Markaby* appears to do the same for HTML generation.

The natural question then, is what possibility is there for Markaby to become, in the future, an official part of the rails core?

The arguments against this are that ERB is good enough, or gets developers closer to the HTML being generated by the engine. The counterpoints are that rails is about elegance in web development, and improving productivity by letting developers stay as high or low level as the situation demands. What are your thoughts?

Scott

* see http://code.whytheluckystiff.net/markaby/

Not sure why it should become "part of the Rails core". Markaby is a lovely way to express code. Having it as a plugin and a choice is fine for me. Wish I could fragment cache Markaby pages tho.

Vish

Markaby is indeed lovely. It seems like a perfect fit to complete the HTML portion of Rails' "ruby everywhere" philosophy.

Part of what's makes rails so great is the constant effort to replace old mechanisms when more expressive or elegant solutions are found - like David's most recent post on start_form_tag. I've seen other developer groups take a "what we have now is good enough" attitude towards changing existing features for what seem like relatively modest gains in elegance. What they forget is that routinely taking the 5% more elegant path makes the difference between an iPod and a Dell DJ.

Markaby could stay a plugin, but there it would stay, waiting to be discovered by developers who are already half way done writing their views in ERB. Actively adopting and encouraging the most elegant solutions makes Rails what it is, and it seems like Markaby is another such opportunity.

Scott

Vishnu Gopal wrote:

Personnaly I'd rather not see markaby become the default way to render templates in Rails. Just one person's opnion.

-Anthony

Personnaly I'd rather not see markaby become the default way to render templates in Rails. Just one person's opnion.

What do you mean by "become the default?" That it becomes the templating language the scaffold templates use? Which markup is used in your own files depends only on the filename of the view.

Personally, I'd like to see Markaby officially sponsored. I enjoy using it more than eRB, and if it were an "official" option, then I could use it without worrying about people who must use my code in the future. I also feel that it enhances code readability in many cases, which is handy when having to read someone else's code.

-Anthony

Sincerely,

Tom Lieber http://AllTom.com/ http://GadgetLife.org/

A slightly different approach is Haml (unspace.ca). It's a bit less down-to-the metal than Markaby, but much more likely to create valid XHTML documents than ERB.

D. Scott Brown wrote:

Is it me, or does Haml look just like Markaby but with rigid whitespace requirements, arbitrary syntax identifiers, and without the benefit being pure Ruby?

// Haml: .tabs   %ul.navigation     %li= link_to 'Member Approval', member_admin_url     %li= link_to 'User Management', user_admin_url,        :class => 'selected'

# Markaby: div.tabs do   ul.navigation do     li link_to 'Member Approval', member_admin_url     li link_to 'User Management', user_admin_url,        :class => 'selected'

Let me know if I've missed something cool that Haml can do.

s.ross wrote:

The main difference from my perspective -- and I'm not incredibly familiar with Markaby -- is that Haml is less like Ruby and more like the outline for your DOM. Markaby *is* Ruby, and that's good. I can't say which is better.

I've found writing Haml is way more productive than writing .rhtml templates. The question is, how do Haml and Markaby compare? It's my understanding that for each Markaby "do" you need an "end". Haml doesn't require this. In fact, you can do this:

- content_for :title do   My Fine Charts - form_tag do   %p Specify date range and projects for reporting.   %p     Begin date (yyyy/mm/dd):     = text_field_tag :begin_date   %p     End date (yyyy/mm/dd):     = text_field_tag :begin_date   %p     Project:     = select_tag :project, options_for_select(Project.new.project_map)   %p= submit_tag 'draw new chart'

%img{:src => @image_url, :alt => 'Chart'}

Notice that the form_tag automagically closed itself? Maybe Markaby does this even cooler. I don't know. Haml is just working well for me right now so I thought I'd mention it in this context.

D. Scott Brown wrote:

+1 for Haml

Markaby is great too, but when writing a view template it helps to think in terms of how the DOM will be structured.

Haml also has various handy built-in ways to generate doctypes, preserve whitespace, and stuff like that. In addition, unlike Markaby, Haml is at its core independent of XHTML... it can be used just as easily to generate any sort of XML-based document.

In the interest of full disclosure, I am a Haml developer... but this is *because*, not *why*, I'm so fond of the language.

Haml education and praise is nice, but does anyone have more opinions on Markaby becoming an officially-supported language for Rails templates?

I have nothing against Haml, but this topic started with question about extending Ruby to the view layer with Markaby. Comparisons with Haml are important, but not to this discussion unless you feel like there is not enough room for two non-eRB templating languages in Rails!

Sincerely,

Tom Lieber http://AllTom.com/ http://GadgetLife.org/

I, personally, would like to see something other than eRuby be the default for Rails. Of course, I'd prefer Haml, but I think it would be feasible to have both Markaby and Haml available. Even just Markaby would be better than eRuby. The basic point is that eRuby is a break with Rails' elegance, and that should be addressed.

Well if you've used Markaby a lot, the fact that it doesn't have a <% %> as opposed to a <%= %> equivalent sometimes seriously sucks. xhtml-careful branch or no, calling to_s on something just to make it work the way I want to is inelegant and un-rails-ish. (I can also rant on about how Camping's meta-magic break simple Ruby stuff like Constants inside it's views and controllers).

Beside Markaby is slower than ERb too. That should settle the point if anything. Rendering in rails as it is, is slow.

Vish

My bad, I interpreted the initial messages in the thread wrong. So let me rephrase: I don't see the need for another HTML template language in Rails. But that's just my opinion.

V/r Anthony

Vish, I think that problem is being resolved in an upcoming release.

Let's refocus this thread back on the original question: What future possibility is there for Markaby (or Haml) be 'blessed' as an official alternative to ERb?

Scott

Vishnu Gopal wrote:

I guess as the inventor of one of the alternatives I should pipe in at this point. I don't think any alternative languages should be included in rails-core. They should be plugins.

What I *would* like to see, is having the markaby and haml repositories added to the default plugin-repository list so that you can easily install them.

./script/plugin install markaby ./script/plugin install haml

But, that's not even required. I think its most important that rails remains focused and clean of any extra-code. Both _why and myself created our languages to be independent of rails too, so that would be odd to make it an official part.

Just my two cents.

-hampton.

I don't think Markaby needs to be in core. Core seems to need some changes though in order for ActionView to work well with Builder. Everything Builder-based broke with the move from instance-variable-based content passing to method-based content passing, and the Markaby plugin (at least when I last used it with Rails a month ago or so) required you to use the deprecated @-ways.

What changes would these be? If someone could give me details I would be willing to work on a patch.

Markaby is super-productive for me and I really like having every Ruby power available to me for constructing the layout (no business logic in the views here).

Evan Weaver

(PS. Back in the day I thought you could get in the default plugin repository by adding yourself to the wiki. Is that no longer true?)

I can understand the arguments for having Markaby included in the core rails. It seems to be the closest way of maintaining the purest Ruby environment so I imagine it could be added to the package. However, there is hardly no documentation on Markaby and even though the learning curve is small a newbie can get frustrated pretty quickly. Its all in the details...

I can understand the arguments for having Markaby included in the core rails. It seems to be the closest way of maintaining the purest Ruby environment so I imagine it could be added to the package. However, there is hardly any documentation on Markaby and even though the learning curve is small a newbie can get frustrated pretty quickly. Its all in the details...

I guess as the inventor of one of the alternatives I should pipe in at this point. I don't think any alternative languages should be included in rails-core. They should be plugins.

Indeed. Rails already includes ERb and Builder (which is a pure-Ruby view tech) templates and there are no plans to include more in core.

What I *would* like to see, is having the markaby and haml repositories added to the default plugin-repository list so that you can easily install them.

There's a new plugin repository underway that'll make this happen.