Usage of haml versus html

Developers
#1

ManageIQ switched recently to use only haml files instead of html.

While using haml still might benefit the majority of the files in the project that has been short anyway even before the haml conversion, the situation with longer and more complicated files is different.

There are several challenges in using haml among which:

  • haml is whitespace sensitive/indentation sensitive which I find hard to rely on during development = it’s very fragile.
  • no closing tags require to track really closely the tabs to see where sections actually end (as opposed to closing tags in html that mark that part clearly) - easily getting lost after 2-3 hierarchies down. so readability of the files is harder.
  • it adds an extra step that converts haml to html - potential penalty on large/complicated files
  • harder to convert more advanced use cases that involve angular directives, etc. (and less documentation/examples online for that)
  • some of the haml files don’t contain RoR code which was the main use case for using haml.

So given the above, I’d like to propose to allow the usage of both haml and html in the project - specifically allowing html for the longer and more complicated use cases.

#2

By html, do you really mean erb?

#3

No, I mean plain html, not erb.
There are some pages like topology (and new dashboards)
that are plain html with Angular, no Ruby involved.

#4

@dclarizio @martin_povolny @hkataria Please chime in with your thoughts.

#5

The one upside to haml is that it generates compliant HTML. In addition, we run haml-lint in the bot which checks additional things. That’s not to say we can’t add something like tidy to the bot to assure it’s structured correctly.

#6

@abonas: I see no problem in using HTML where there’s no need to call helpers and including larger chunks of repeated code.

If you have nicely formated HTML code that does the job for you I see no benefit in converting it to HAML.

Especially in case of Angular it makes perfect sense to me to have static HTML.

#7

@martinpovolny I completely agree with you, I started this thread after I was specifically asked to convert the html into haml during code review of the Topology widget PR (3524) where there is only Angular code.

#8

I am +1 on @abonas suggestion that @martinpovolny agrees with.

@dclarizio @hkataria @tenderlove @matthewd @Fryguy Please +1 if you agree with proposal or provide your opposing opinion.

#9

+1 the argument makes sense.

#10

+1

#11

@abonas @Fryguy @dclarizio @martinpovolny @hkataria Seems like we have consensus to allow usage of straight HTML where

  • it does not call Ruby
  • it is nicely formatted
  • Angular as main use case for static HTML
#12

@chessbyte that’s great. I’d like to know what is considered as nicely formatted, which tools and validations the html has to pass. thanks.

#13

@abonas I will defer the term “nicely formatted” to @martinpovolny. One objective measure may be running it through Tidy

#14

+1 agree with above suggestions.

#15

Late to the discussion but…

In places we do use HTML, it means we can’t reference any other assets - no image references without image_path, and we do have to handle translation in Javascript (again, no _(...) in pure html).

Which IMHO severely reduces the set of templates that can realistically be HTML.

Just my 2c :slight_smile:

Translations in Angular controllers and related code