Hvis du bor og puster inn Ruby land og har gitt Haml et skudd før, vil du nok allerede vite et par argumenter jeg skal gjøre. Jeg tror det er likevel en god ide å følge med, fordi du kanskje allerede har bestemt deg for å bruke en mer minimalistisk templerende motor, og jeg vil gjerne se fordelene med Slim-tilbud også.
Før vi dykker inn i hvorfor Slim er kult, vil jeg dekke hva Slim faktisk er og hva det gjør for deg. Dokumentasjonen summerer dette ganske bra:
"Slim er en rask, lett, templerende motor med støtte for Rails 3 og 4".
Du kan også bruke den med Sinatra og til og med vanlig Rack. Så, hvis du er litt lei av å bruke ERB til å skrive maler, eller hvis du ikke er super fornøyd med hva Haml har å tilby, er Slim akkurat det rette treet for å bjeffe opp.
Med hensyn til syntaxen forsøkte folket bak Slim å finne et svar på følgende spørsmål: "Hva er minimumet som kreves for å gjøre dette arbeidet?" For å skrive den minimale mengden av front-end-kode mulig, høres dette ut som det rette spørsmål å spørre.
Gir Slim en perfekt løsning på alle dine templerende bekymringer? Sannsynligvis ikke, men helt ærlig, det kan bare tilby det beste! Er det lett å lære? Jeg tror det, men det er vanskelig å vite hva andre anser lett. Jeg vil si dette, skjønt: det tar litt å bli vant til, men det er definitivt ingen rakettvitenskap. Så du trenger ikke å føle deg skremt hvis du er litt ny på den kodende siden av ting. Vil du ha det bra med det? Absolutt!
Så, hvorfor Slim? Svaret er ganske greit, tror jeg. Ditt oppslag skal være så lesbart og vakkert som mulig! Du bør ha det bra med å jobbe med det, og jo mindre tid du trenger å bruke wading gjennom tonnevis, betyr noe bedre.
Hva er vakkert, kan du spørre? Selvfølgelig, det er ikke et svar jeg vil prøve å takle, men å være minimal i den forbindelse gjør det sjelden vondt. Hva med å bli super kryptisk fordi den templerende motoren forsøker å være super smart i å være minimal? Det er en rettferdig bekymring, og du vil gjerne høre at laget bak Slim tar dette veldig alvorlig. De vil fjerne så mye som mulig fra vanlig gammel HTML og avsløre bare de essensielle delene, alt uten å bli for kryptisk. Kjerneteamet forsøker å gå et skritt videre enn det, og de er veldig opptatt av estetikken til Slim-koden. Ganske bra, tror du ikke?
Er det ikke mye bedre hvis du bare kan se på en mal og være i stand til lett å fordøye hva som skjer? Maler kan bli et veldig "overfylt" sted - selv om du bruker intelligent bruk av deler - og som en konsekvens vil du redusere mengden støy til det absolutte minimum.
Har du kanskje prøvd den innrykkede Sass (.sass) syntaks? Jeg håper du har, fordi det er bare ren dope! I så fall vil du sannsynligvis ha en lignende forståelse for hva Slim har å tilby. Det er også hvite romfølsomme, noe som fører til virkelig kortfattet og lesbar kode. La oss ta dette stykket HTML / ERB kode og sammenligne det med Slim.
<%= full_title(yield(:title)) %> <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track' => ekte%> <%= javascript_include_tag 'application', 'data-turbolinks-track' => ekte%> <%= csrf_meta_tags %><%= link_to "sample app", 'root_path', id: "logo" %><%= yield %>
La oss se på Slim-ekvivalenten:
doktype html html hodetittel = full_title (yield (: title)) = stylesheet_link_tag 'application', media: 'all', 'data turbolinks-track' => sant = javascript_include_tag 'application', 'data turbolinks-track' > true = csrf_meta_tags body header.navbar .logo = link_to "sample app", "root_path", id: "logo" nav ul.navbar-høyre li = link_to "Hjem", "root_path" li = link_to "Help" help_path 'li = link_to' Logg inn ',' login_path '.main = yield
Det første folk ofte gjenkjenner er, "Hei, ingen lukkerkoder!" Cool? Visst, du er ikke vant til syntaksen ennå, så det kan se litt fremmed først, men jeg er sikker på at du kan sette pris på hvor kortfattet det leser. Ingen venstre / høyre vinkelbeslag, og du trenger ikke å skrive divs og minimalistiske velgere, så i stedet kan vi fokusere på navnet ids og klasser har. Det føles mye mindre rotete og mer organisert, tror du ikke?
Til sammenligning, her er Haml-versjonen. Det er egentlig ikke ment som en mulighet til å bash Haml-det bare viser deg hvor likt det er, men også at Slim går et skritt videre med sitt valg av minimal syntax. Resultatet er at det er enda mer elegant enn Haml, tror jeg.
Hvorfor gå så minimal, men gjør fortsatt at jeg skriver inn %
tegn over alt? Pekefingeren har ingen spesiell motivasjon til å gripe Shift-5 hele tiden. Kan du tilpasse atferd? Ganske sikker, eller i det minste håper jeg det! Men designet virker litt feil i den forbindelse og mindre spartansk sammenlignet med Slim. Jeg skjønner at dette også er et spørsmål om smak, men jeg vil forlate det ved det.
!!! % html% head% title = full_title (yield (: title)) = stylesheet_link_tag 'application', media: 'all', 'data turbolinks-track' => sant = javascript_include_tag 'applikasjon', 'data turbolinks-track' => true = csrf_meta_tags% body% header.navbar .logo = link_to "sample app", "root_path", id: "logo"% nav% ul.navbar-høyre% li = link_to "Hjem", "root_path"% li = link_til "Hjelp", "help_path"% li = link_to "Logg inn", "login_path" .main = yield
Før vi hopper inn i de kjøttfulle delene, la meg være puffy et øyeblikk og oppsummere hva jeg tror gjør læring Slank en verdig investering av tiden din:
Når det gjelder programmeringserfaring, vil du prøve å gi deg en rask rundtur, før du begynner å bruke Slim, hvis du anser deg for å være mer på newbie-siden. Når folk snakker om maler, betyr de for det meste vanlig HTML-oppslag med dynamisk kode som ofte brukes til flytkontroll, objektinjeksjon eller delvis maling (partials) rendering. For eksempel, når en kontroller gir deg instansvariabler som kan brukes av visningen via (substitutt) variabel substitusjon for å vise attributter fra den objekten. Alt dette skjer via malprosessoren etter eget valg - ERB, Haml, Slim og lignende - som kombinerer alle webmaler i en siste nettside. Maler kan også brukes til å generere XML- og RSS-feeds, samt andre former for strukturerte tekstfiler.
Med maler kan du definere ulike "layouts" som håndterer bestemte deler av nettstedet ditt, samt dataene som må vises systematisk med den minste repetisjonen. Siden du begynte å spille med Rails, har du sikkert brukt ERB for akkurat slike scenarier. ERB tar de rene tekstdelene, overfører dem til det endelige dokumentet og behandler bare kode som er merket som sådan. Jeg går ikke inn på detaljer hvordan ERB fungerer og antar at du har en grunnleggende forståelse før du dykker inn i Slim. Jeg vil ikke anbefale å bruke Slim hvis du ikke allerede er kjent med Rails standard måte å templere på siden du vil ha en mye enklere tid å spille med Slim hvis du forstår hvordan dette virker ut av boksen i Rails.
Nedenfor er et grunnleggende ERB eksempel på en mal som viser en samling av oppdrag som er knyttet til en @middel
gjenstand. Rett under, bruker den også en metode fra en Ruby Gem å paginere @missions
samling.
<% if @agent.missions.any? %>Oppdrag (<%= @agent.missions.count %>)
Dette er en liten del av en mal som viser pent at det ikke er noe mer enn en statisk HTML-del som har noen dynamiske injeksjoner fra noen Ruby-koden. Hvis vi ikke brukte maler som dette, må vi manuelt skrive kode for hvert nytt objekt som vi vil se vises på en side. Ikke sikker på deg, men jeg kan ikke forestille meg et større mareritt eller bortkastet tid enn det. Maler gir oss et nyttig verktøy for å gjøre visningslaget ditt smart og dynamisk uten å gjenta oss selv.
Som du også kan se fra dette eksemplet, lar maler oss bruke delvise maler som vi kan gjengi når det er nødvendig. Her ville vi ha en _mission.html.erb
delvis et sted, noe som hjelper oss å iterere over en samling av @oppdrag
Objekter, som igjen blir oppført i vår oppdrag
klasse.
Som du kan se, er maler ikke noe magisk, men det er veldig praktisk å gjøre utviklingen av webapps mye mer effektiv og organisert. Jeg ville bare sørge for at vi alle er på samme side med dette før du går inn i Slim.
Hvis du liker å bruke disse verktøyene, er det helt greit. Ingenting galt med det. Saken er, hvis du er ute etter noe smartere som er mer minimalistisk, er det vanskelig å finne noe som går lenger enn Slim. For meg er det den mest strømlinjeformede templerende løsningen i Ruby land som jeg kjenner til. De jobber fint, så det handler om personlig preferanse.
Ingen overraskelse, det er en perle for det.
perle "slanke skinner"
bunt installasjon
Det er det, vi er alle satt. Fordi du installerte denne perlen, vil Slim bli lastet og initialisert når appen din laster. Også, for din bekvemmelighet, når du genererer kontrollører via skinner genererer kontrolleren
, du vil automatisk få .slank
se filer for visningen din-.html.erb
filer ikke mer. Det fungerer det samme med stillasene, men jeg håper du ikke bruker dem virkelig!
For å demonstrere denne oppførselen for folk som er ny for å bruke Rails generatorer, vil jeg opprette en kontroller for hemmelige serviceoperatører som har alle standard REST controller-handlinger:
skinner genererer kontroller SecretServiceOperatives indeks ny skape show redigere oppdatering ødelegge
Blant annet får du alle .slank
filer du trenger. Rails legger ekstra .html
i det også, du kan bli kvitt det hvis det plager deg selvfølgelig. Alt som betyr noe er at den tynne filtypen er allerede der, og at den er klar for forbehandling av Slim-koden. Jippi!
... påkalle slank lage app / visninger / secret_service_operatives lage app / visninger / secret_service_operatives / index.html.slim lage app / visninger / secret_service_operatives / new.html.slim lage app / visninger / secret_service_operatives / create.html.slim lage app / visninger / secret_service_operatives / show.html.slim lage app / visninger / secret_service_operatives / edit.html.slim lag app / visninger / secret_service_operatives / update.html.slim lag app / visninger / secret_service_operatives / destroy.html.slim ...
Det neste trinnet ville være å åpne applikasjonsoppsettet og å erstatte boilerplate-koden med noe Slim. Også, ikke glem å endre navn på application.html.erb
fil til application.slim
(eller application.html.slim
hvis du vil). Vi har allerede slanket litt, selv om filnavnet har mistet litt vekt.
doktype html html hodetittel = stylesheet_link_tag 'application', media: 'all', 'data turbolinks-track' => true = javascript_include_tag 'søknad', 'data-turbolinks-track' => true = csrf_meta_tags body header.navbar. logo = link_to "Spion app", "root_path", id: "logo" nav ul.navbar-right li = link_to "Hjem", "root_path" li = link_to "Hjelp", "help_path" li = link_to "Registrer deg" , 'sign_up_path' li = link_to "Logg inn", 'login_path' .main h1.welcome Velkommen til Boss Level Slim Templates! = utbytte
Ikke noe fancy, men en god start - og så lett som mulig, tror jeg.
Som en side notat, hvis du noen gang er nysgjerrig på hvilken versjon av perlen du har installert, vil denne lille kommandoen fortelle deg. Det er også praktisk for enhver perle også, selvfølgelig:
bunt show "slanke skinner"
Den forteller deg hvor den er lagret og hvilken versjon denne perlen har for øyeblikket. Utgangen ser slik ut:
/Library/Ruby/Gems/2.3.0/gems/slim-rails-3.0.1
For Sinatra-entusiasterne blant dere ønsket jeg å nevne hvordan du kommer i gang også. Først må vi installere perlen, selvfølgelig.
perle installasjon slank
Og etter det er du nesten ferdig. I Sinatra app, trenger du bare å kreve Slim, og du er god å gå.
krever 'sinatra' krever 'slank' get ('/') slank: index __END__ @@ index doctype html html hode tittel Slim Maler kropp h1 Boss Level Ruby Maler Med Slim
Her brukte jeg en inline-mal til å skrive Slim-oppslaget i samme fil og fortalte Sinatra at jeg vil bruke Slim for indeksfilen når den lager en få
forespørsel til roten banen. Jeg trengte bare å referere inline-malen inne i en krøllete braces-blokk. Det du ser under @@-indeksen
-som betyr indeksmalen - er alle hvite plassfølsomme Slim syntaks.
Tid til å vise deg hvordan du skriver litt Slim.
La oss starte med den enkleste, doktypedeklarasjonen. Som du sikkert vet og allerede har glemt, må dette deklareres på toppen av HTML-dokumentet ditt - før selve stikkord. FYI, det er ikke en HTML-kode og instruerer nettleseren om versjonen av HTML-siden.
Blant de forskjellige versjonene for , det er bare ett for HTML5:
-takk gud! -som er akkurat det vi får når vi skriver
doktype html
eller doktype 5
i Slim.
doktype html html hode doktype 5 html hode
#
og klasse snarvei .
Å skrive front-end-kode betyr massevis av klasser og aldri så få ids-jeg håper. For å unngå å skrive disse om og om igjen, møter Slim deg mer enn halvveis, og lar deg kortslutte hele prosessen i utgangspunktet. La meg vise deg hva jeg mener. Ta følgende Slim kode:
#logo h1.header .evil-wrapper h2 # forfatter-navn ul.books
Dette blir kompilert til denne HTML-utgangen:
Som du kan se, tyder punktet på Slim som du vil bruke en klasse, og navnet som følger er det du vil nevne det. Det samme gjelder for ids-du bruker bare hash-symbolet (aka pound sign) som gjør kunsten. Astute lesere anerkjente sikkert at versjoner uten ledende tag utløser opprettelsen av en div med tilhørende klasse eller id som kan ses for og
. Ganske hendig, tror du ikke?
Du kan også være mer uttrykksfulle i Slim-koden din hvis du vil. Ingen hindrer deg i å skrive dine gode oljeklasser og ids for hånd. Hvis du føler deg festet på det, gå for det! Jeg liker den mer kortfattede versjonen fordi det også lar meg unngå å skrive sitater og gjentatt tekst hele tiden. Det er opp til deg - det som gjør deg glad! Koden under er litt mer ordentlig, men gjør samme HTML som ovenfor:
div h1 div h2 ul
Nå er det ikke noe å skjønne? Tenk deg alle disse fryktede HTML-kodene som du ikke trenger å skrive deg selv, pluss å bli kvitt alt overskytende vinkelbeslag. Sikker på at kodeditoren din kan gjøre mye av dette arbeidet, men leser redaktøren din også koden for deg? Nøyaktig!
Når du kommer tilbake til å lese koden din, vil du også ha et kortfattet dokument som er super lett å fordøye visuelt. Jeg tror dette enkle eksemplet viser best hva et verktøy som Slim har å tilby. Det er disse små tingene som legger til et flott verktøy og tidsbesparelse i det lange løp. Selv om du bare bruker den til akkurat den funksjonaliteten og ignorerer de andre mer avanserte funksjonene for nå, ville byttet til Slim allerede betale stor tid.
La oss si at du har flere koder som du vil ha inline for å være mer kompakt eller hva som helst. Så i stedet for å bryte til en ny linje, kan du kjede dem ved å skille disse kodene med et kolon :
. Begge eksemplene nedenfor gir samme utdata.
ul li.first a href = "/ a" En lenke li a href = "/ b" B link ul li.first: a href = "/ a" En lenke li: a href = "/ b" B lenke
Den andre versjonen er mer minimal på grunn av de innrammede kodene og vil være min preferanse. Tross alt, kompakt er bra, nei? Jeg tror denne saken viser pent at Slim jevnt balanser mellom kompakt og kryptisk. Ja, det tar litt å bli vant til, og i noen tilfeller er det ekstra nyttig attributt wrappers (se mer om wrappers nedenfor). Kall meg gal, men jeg er ganske sikker på at du vil lese Slim som vanlig HTML-oppslag i en jiffy.
Skrive tekst er så enkelt som du forventer, selvfølgelig. Bare legg den på etter kodene dine.
h1 # velkommen-header Din funky velkomstmelding går her!
Din funky velkomstmelding går her!
Ingenting mer å legge til, enkelt som det kan være!
HTML-attributter, som gir ytterligere informasjon om kodene, kan inkluderes som følger:
a href = "http://slim-lang.com" title = "Slim hjemmeside" Gå til Slim hjemmeside img alt = "James Bond poserer sammen med M" src = "images_8 / an introduction-to-slim-templates_3. png "/
http://slim-lang.com "title =" Slim Homepage "> Gå til Slim hjemmeside
Du kan i utgangspunktet kjede dem på og Slim vil skille det fra tekstinnholdet - hvis det er til stede. Hvis du ser nøye ut, kan du se at vår img
taggen har et skråstrek, som eksplisitt lukker merkene i Slim. For bilder eller flere sammenfylte koder, er dette sikkert nyttig. For øvrig krever ikke HTML5 at du skal skrive attributtnavnene i små bokstaver eller å bruke anførselstegn rundt attributtverdier. Det anbefales likevel standard praksis av W3C.
Hvis du har flere selektorer som klasser eller ids per tag, kan du også skrive dette mer kortfattet ved daisy-chaining dem. Disse valgene blir automatisk avgrenset av hvitt plass.
h2 # big-header.agent-header.tagline Funky overskrift h3.small-header.agent # 007.tagline Liten, skummel overskrift
Funky overskrift
Liten funky overskrift
Ikke at å ha alle disse ids og klassene blandet som dette representerer beste praksis eller noe, men det er lett å se hvordan Slim fungerer i et slikt innviklet eksempel. Ganske kul, va? Forsiktig, men å spre disse velgerne over flere linjer vil ikke fungere uten attributtpakker (se neste avsnitt).
Et annet alternativ ville være å bruke en rekke med strenger eller bare symboler for å fusjonere i attributter.
h2 class = ["agent-header", "tagline"] Funky overskrift h3 class =: agent,: double_o_seven,: tagline Liten funky overskrift
Funky overskrift
Liten funky overskrift
I min bok vil jeg kalle denne en god å vite, men det er ikke noe jeg prøver å bruke aktivt. Det kan være nyttig hvis du vil interpolere noe, antar jeg.
Slim tilbyr deg wrappers for å gjøre dine attributter enklere å lese. Det kan ikke være nødvendig hele tiden, men det er praktisk å vite om en tag med mange attributter trenger litt taming. Du kan bruke en av følgende avgrensere til å bryte attributter: ,
[]
og ()
.
en href = "http://slim-lang.com" title = "Hjemmeside" Gå til hjemmesiden en href = "http://slim-lang.com/about.html" title = "Om side " Gå til siden h2 [id =" big-header "] Funky overskrift h3 (id =" small-header ") Noen andre funky overskrift
Gå til hjemmesiden Gå til siden omFunky overskrift
Noen andre funky overskrift
Hvis det er en enklere måte for deg å organisere oppslaget, gå for det! Som illustrert av den andre en
og h3
koder, kan du til og med spre tilskudd og selektorer over flere linjer. Indrykk synes å bli håndhevet svært forgivingly med hensyn til hvitefelt følsomhet. Mitt gjetning er at det ikke vil være lenge, og du trenger ikke mye wrappers. Du blir vant til barebones Slim syntaks på kort tid og lagre dem for spesielle anledninger - som du sikkert burde.
For inline-tagger kan wrappers komme til nytte hver eneste gang. Som du også kan observere i eksemplet nedenfor, kan du bruke mellomrom med avgrensere for å gjøre det enda mer lesbart - bare en side notat.
ul li.long-link: en href = "http://slim-lang.com" title = "Hjemmeside" Gå til hjemmesiden li.long-link.class.with-id: a [href = " http://slim-lang.com/about.html "title =" Om side "] Gå til siden li.c-linken: a (href =" / c ") C-lenke li: a [href =" / d "] D lenke
Har noen sagt interpolering? Innen siterte attributter kan du bruke Ruby til å interpolere koden om nødvendig. Et enkelt eksempel bør være nok til å illustrere denne oppførselen:
a href = "http: // # url" Gå til # url
Igjen, ikke noe du kan bruke på daglig basis, men det er sikkert bra å ha med deg i vesken din. Attributtverdiene vil bli rømt som standard. Hvis du trenger atferden deaktivert, bruk bare a ==
.
a href == "http: // # url" Gå til # url
Du kan bruke full-on Ruby til å spille med dine attributter også. Bare kast et like tegn der du vil at noen Ruby-kode skal utføres, og du er klar til å gå. I den andre artikkelen finner du mer informasjon om utlevering av Ruby-kode i Slim-maler.
ul li class = agent.role a href = (path_to_agent agent) = agentnavn
Det betyr selvsagt også at du kan bruke enkle booleaner på samme måte i dine attributter også.
input type = "text" disabled = false input type = "text" disabled = true input type = "text" deaktivert = null
Groovy, la oss gå videre!
Jeg håper du har en god følelse av hvorfor Slim er et godt valg for alle dine templerende behov i Ruby land. Hvis du fremdeles foretrekker å bruke Haml eller ERB for øyeblikket, kan du vokse en appetitt for Slim over tid. Jeg sier ikke at det er en oppkjøpt smak eller noe, bare at det ikke er noe som mange mennesker plukker opp tidlig i karrieren deres - kanskje fordi de ennå ikke har fått vondt av å skrive alt det overskytende merket igjen og igjen. Denne artikkelen skal gi deg det grunnleggende du trenger for å komme i gang.
Slim har mer å tilby, selvfølgelig, spesielt noen få avanserte funksjoner som du definitivt vil ta en titt på. I neste artikkel begynner vi med en mer detaljert seksjon om å skrive ut Ruby-kode i malene dine - og mye mer selvfølgelig. Ser deg der!