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 (http://unspace.ca/discover/haml/).
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.