RoR: HAML of ERB? Waarom niet gewoon plain ruby?

Door Gamebuster op donderdag 26 september 2013 13:22 - Reacties (6)
Categorie: if(post.relatedTo("programming")), Views: 2.105

Ruby is leuk, maar in het geval met Ruby on Rails zal je uiteindelijk toch HTML moeten genereren voor je webapp. Zit je lekker te werken in Ruby, mag je opeens HTML gaan schrijven (blegh) en dit gaan combineren met inline ERB tags (dubbelblegh)

Met die gedachte is HAML/SLIM ontworpen. HAML wordt echter niet altijd even geliefd door iedereen, deels om het feit dat het op basis van significant whitespace werkt en vast nog wel meer redenen (to be honest: Ik heb het zelf nooit gebruikt)

In een brainfart dacht ik daarom: Wat is er mis met een puur Ruby oplossing om HTML te genereren; Voorbeeld van een layout: (filename zou dan bijv. layout.html.rb zijn)

Ruby:
1
2
3
4
5
6
7
8
9
10
11
12
13
html lang: I18n.current_locale {
    head {
        title @title
        meta charset: "utf-8"
        stylesheet_link_tag "application"
        javascript_include_tag "application"
    }
    body id: "#{params[:controller]}_#{params[:action]}".gsub(/^[a-z0-9_]+/, "-") {
        render "head"
        div class: "container", &content
        render "foot"
    }
}



Je kan gewoon bestaande methodes/helpers aanroepen. Via method_missing vang je calls naar niet-bestaande methodes af (body, head, html, div, enz) en roep je content_tag aan met de methodname, meegegeven args en block.

Simpel te implementeren, plain Ruby en ziet er naar mijn mening beter uit dan zowel ERB als HAML.

Een simpele tabel:

Ruby:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
table class: "table" {
    thead {
        tr {
            th User.human_attribute_name "name"
            th User.human_attribute_name "email"
            th
        }
    }
    tbody {
        @users.each do |user|
            tr {
                td link_to(user.name, user)
                td user.email
                td link_to(user.name, user, method: "delete")
            }
        end
    }
}

Volgende: Videobewerking 09-'13 Videobewerking
Volgende: git pull 09-'13 git pull

Reacties


Door Tweakers user sys64738, donderdag 26 september 2013 14:25

Wat is er mis met good-old HTML? Ruby is een hele mooie taal en geschikt voor van alles en nog wat (waaronder application logic en controllers) maar voor mark-up is html gewoon beter. En je browser snapt het out-of-the-box... ook handig.

Developers zijn hun favoriete taal vaak als hamer en ineens lijkt alles om ze heen op een spijker. Maar als een timmerman een plank moet inkorten, pakt die toch ook niet zijn hamer.

Daarnaast is het juist netjes om je view te scheiden van je controller en model. En het heeft ook als voordeel dat je je HTML / front-end development door iemand anders kunt laten doen.

Door Tweakers user jbdeiman, donderdag 26 september 2013 14:51

Daar is niets mis mee denk ik, gewoon HTML-en, maar het kan soms wel gemakkelijker.
Ik zie hier de ruby achterkant ook meer als een soort van "template" systematiek, het is wel een grappig idee, maar ik zou dan deze variant gebruiken om templates (of een template) te bouwen, waarbij &content in de template een placeholder is, niet gelijk de inhoud van de content variabele op dat punt.

Op die manier kan je best leuk/ eenvoudig templates creëren, die prima leesbaar zijn ook, al hou ik het vaak liever bij HTML, omdat ik dat behoorlijk ken.

Door Tweakers user ameesters, donderdag 26 september 2013 14:55

ga het maar eens aan een designer uitleggen

Door Tweakers user Gamebuster, donderdag 26 september 2013 15:25

designers werk ik toch nooit mee, frontend werk doe ik altijd zelf. Alleen designs krijg ik soms aangeleverd als PSDtje.

Door Tweakers user Mac_Cain13, vrijdag 27 september 2013 08:51

Op zich lijkt me niets mis met jou idee, zeker als je Ruby fan bent en dit goed bij je manier van denken past kan het goed werken. Er kunnen wel een aantal nadelen aan kleven, vooral als je in een wat groter team werkt of op lange termijn kijkt. In je eentje op korte termijn is bijna elk systeem prima te gebruiken namelijk, je loopt bijna nooit tegen de beperking aan dat je het zelf niet meer snapt namelijk.
Het is sowieso leerzaam om dit eens te maken natuurlijk en te kijken waar je uitkomt en wat eventuele problemen zijn. :)

Grote nadelen lijken me dat je de hele HTML spec moet implementeren (domweg aardig wat werk), het wel eens onleesbaar kan worden als je een wat grotere lap code hebt en elementen met meerdere classes, een id, een alt, title en src attribuut. Hoe zit het er dan uit? Vooral als er veel data uit Ruby moet komen.

Daarnaast is het bij het werken in een team onhandig. omdat je daar vaak een frontender/designer hebt en die zit helemaal niet te wachten op iets wat geen HTML is. Ook het overdragen van je code aan iemand anders wordt moeilijker, vandaar dat veel template talen dicht bij HTML proberen te blijven. (Sommige kun je ook van zeggen dat ze lastig zijn voor designers, maar dan zijn ze hopelijk nog wel goed gedocumenteerd en met een community waar je vragen aan kunt stellen.)

Door Tweakers user Gamebuster, vrijdag 27 september 2013 14:48

Grote nadelen lijken me dat je de hele HTML spec moet implementeren (domweg aardig wat werk), het wel eens onleesbaar kan worden als je een wat grotere lap code hebt en elementen met meerdere classes, een id, een alt, title en src attribuut. Hoe zit het er dan uit? Vooral als er veel data uit Ruby moet komen.
De hele HTML spec implementeren? Dat is niet nodig. Er wordt gebruik gemaakt van het feit dat de methodes niet bestaan; wanneer de methode die aangeroepen wordt niet bestaat (en het is dus ook geen helper zoals javascript_include_tag), dan wordt de method-call omgezet in een HTML tag met behulp van een fallback methode die aangeroepen wordt vanuit alle niet-bestaande method-calls. In Ruby doe je dit met method_missing en de implementatie van zo'n methode is vrij simpel. Voor performance zou je bekende en/of veelgebruikte HTML-tags vooraf kunnen implementeren.
Daarnaast is het bij het werken in een team onhandig. omdat je daar vaak een frontender/designer hebt en die zit helemaal niet te wachten op iets wat geen HTML is.
Daar heb ik sowieso zelf nooit mee te maken, niet prive, op mijn werk of met freelance klusjes.
Ook het overdragen van je code aan iemand anders wordt moeilijker, vandaar dat veel template talen dicht bij HTML proberen te blijven.
Moeilijker, maar met die gedachte kan je nooit wat nieuws maken. Verder is ROEL plain ruby: Men hoeft geen nieuwe syntax te leren. Mijn codevoorbeeld hierboven lijkt dan ook naar mijn mening vrij intuïtief voor Ruby on Rails ontwikkelaars te zijn.

[Reactie gewijzigd op vrijdag 27 september 2013 14:49]


Reageren is niet meer mogelijk