I min tidligere veiledning berørte jeg hvordan du bruker Ember.Object
å definere modellene dine og jobbe med datasett. I denne delen ser vi nærmere på hvordan Ember bruker håndteringsrammene for å definere appens brukergrensesnitt.
De fleste server-side utviklere er vant til å bruke maler for å definere markup som vil bli dynamisk fylt på fluen. Hvis du noen gang har brukt ASP.NET, ColdFusion, PHP eller Rails, så er det ganske sikkert du vet hva jeg snakker om.
JavaScript Client-side templering har virkelig tatt seg av sent, spesielt på grunn av fokus på å bygge mer desktop-lignende erfaringer. Dette betyr at flere av behandlingen er utført på klientsiden, idet data hovedsakelig blir trukket via API-forespørsler på server side.
Jeg husker å skrive om klientsiden maler for en tid siden da jQuery Template plugin ble først utgitt. Nesten tre år senere er det fortsatt det mest lesede innlegget på bloggen min, og viser hvordan interessen for templering på klientsiden har steget. Siden da har en rekke andre rammer blitt utgitt, og tilbyr rike funksjoner og støttende samfunn. Håndtak er et av de mest populære alternativene og rammen valgt av Ember-prosjektet for å drive det er templerende behov. Dette er fornuftig som Handlerbars ble opprettet av Ember.js medstifter og kjerneamedlem, Yehuda Katz. Vær oppmerksom på at jeg ikke planlegger å gjøre sammenligninger mellom templerende rammer, og jeg vil strengt fokusere på Handelbars siden dette er hva Ember.js bruker som standard.
I de forrige artiklene viste jeg noen veldig grunnleggende maler i koden:
To ting som skiller seg ut er typegodkjenningen for manusetiketten og de krøllete båndene som virker som avgrensninger for uttrykkene som håndtakene skal reagere på. Dette er veldig typisk syntaks som jeg vil diskutere mer detaljert snart, og du vil bruke konsekvent som du bygger Ember-maler.
Til tross for at håndtakene bruker et spesielt syntaks, på slutten av dagen jobber du først og fremst med standard HTML-oppslag. Handlebars tjener til å injisere innhold i denne markeringen for å gjøre data til brukeren. Det gjør dette ved å analysere de avgrensede uttrykkene og erstatte dem med dataene du har bedt Håndterker til å jobbe med. Når det gjelder Ember, gir håndtakene krokene og Ember bruker dem. Disse dataene kommer vanligvis fra kontrolleren din (husk at kontroller fungerer som grensesnitt til modellene dine).
Det første som noen mal trenger er en definisjon av skriptetikett. De fleste av dere har sikkert definert skriptetiketter for å laste inn JavaScript-biblioteket ditt. Faktisk har du allerede gjort dette for å laste Handlebars til ditt Ember-prosjekt:
Det er en liten forskjell med å bruke den til å definere en mal. Først angir vi en type
attributt for "tekst / x-styrer". Dette type
blir ignorert av nettleseren, men la teksten bli tilgjengelig for inspeksjon og tillater Ember å identifisere maler i appen. I tillegg bruker Ember et datatributt kalt "data-template-navn" som Ember kan bruke til å knytte bestemte deler av søknaden din med en mal. For eksempel definerer følgende deklarasjon en mal med navnet "ansatt":
Når søknaden starter, skanner Ember DOM for type = "text / X-styret
, kompilerer malene den finner, og lagrer dem i en egenskap av Ember-objektet, som kalles Ember.TEMPLATES
som den bruker til å finne ut hva som skal gjengis for en gitt rute. Dette er grunnen til at Embers navnekonvensjoner er så viktige. I eksemplet ovenfor blir denne malen automatisk knyttet til ansattes rute og kontroller du opprettet i søknaden din. Igjen kan jeg ikke stresse nok hvordan disse navngivningskonvensjonene vil gjøre utviklingen enklere.
Ember er avhengig av nettadresser for å bestemme hvilke ressurser som må brukes og maler som må gjengis. La oss forestille deg at du hadde en profilside med nettadressen "/ profil". Du ville ha en ressurs, kalt profil
som ville laste bestemte ressurser for den URL-adressen (som et ruteobjekt), og du vil også ha en mal med samme navn. Vi har gjennomgått definere ressurser og ruteobjekter i del 2 av min Ember-serie, så hvis du ikke er sikker på hva jeg diskuterer, vær sikker på å hoppe tilbake dit for å oppdatere deg selv på dette.
Når du besøker denne nettadressen, vet Ember at den trenger å laste disse ressursene og analysere malen du har definert. Det gjør dette via navnekonvensjonene, og vet at fordi du gikk til "/ profil", må den laste ressursene som er definert i profil
, og gjengitt malen, navngitt data-mal-name = "profil"
.
Når du går over navnekonvensjonene igjen, vil du se at ruten, kontrolleren og malen er alle bundet sammen ved hjelp av samme nettadresse, med unntak av at malen er stavet i små bokstaver. Dette gjør det mulig for Ember å styre alt bak kulissene uten at du trenger å gjøre mye ledninger opp.
Det er også viktig å merke seg at hvis du erklærer en mal uten en data-mal-navn
attributt, vil Ember anta at det er Application-scoped-mal - den brukes vanligvis som en nettsidebrede mal for å lage brukergrensesnittelementer, for eksempel overskrifter, bunntekst og navigering. Og hvis du ikke spesifikt definerer en mal for et program eller en ressurs (for eksempel for en URL), gjør Ember det automatisk for deg for å sikre stabilitet og konsistens i appen din..
Det neste trinnet er å inkludere merket ditt og de avgrensede uttrykkene du vil bruke til å representere dataene dine. Uttrykk er avgrenset, via dobbeltkrøllede braces som gjør at de enkelt kan identifiseres og analyseres med data som sendes fra din kontroller. Her er et eksempel:
I dette tilfellet er det fornavn
og etternavn
uttrykk vil bli analysert av Ember og erstattet av faktiske data. I tillegg setter Ember opp observatører slik at når dataene dine endres, blir malen din automatisk oppdatert og oppdateringene gjenspeiles til brukeren av appen din.
Så langt har jeg vist deg et veldig enkelt eksempel, men takeaway er det:
Dette gir mye fleksibilitet i hvordan du strukturerer brukergrensesnittet. La oss fortsette å se på funksjonene som er tilgjengelige.
Husk at Ember bruker håndtak, slik at du har tilgang til sin fulle bredde av uttrykk her. Betingede uttrykk er et must, for å gjøre nesten alt nyttig. Handlebars tilbyr ganske mange alternativer.
La oss si at jeg hadde et JSON datasett som så ut som dette:
"elementer": ["title": "Tearable Cloth Simulation i JavaScript", "url": "http://codepen.io/stuffit/pen/KrAwx", "id": 5592679, "commentCount": 20, "poeng": 127, "postedAgo": "1 time siden", "postedBy": "NathanKP", "title": "Netflix nå større enn HBO", "url": "http://qz.com / 77067 / netflix-nå-større-enn-hbo / "," id ": 5592403," commentCount ": 68," poeng ": 96," postedAgo ":" 2 timer siden "," postedBy ":" edouard1234567 "
Hvis jeg ønsket å sikre at tittel
Data er tilgjengelig, jeg kunne legge til en betinget "if" -oppstilling ved å bruke #hvis
uttrykk:
#if item.title
Dette sjekker for å se om item.title
er ikke udefinert, og fortsetter å behandle de påfølgende uttrykkene for tittel
, postedAgo
og Postet av
datauttrykk.
Siden denne datasettet inneholder mer enn en "plate", er det trygt å anta at vi sannsynligvis vil sløyfe over hvert element av punkt
. Det er der #Hver
uttrykket kommer inn i spill. Den lar deg oppsummere over en liste over objekter. Så, igjen, med tanke på at maler er en kombinasjon av markup og Handlebars uttrykk, kan vi bruke #Hver
uttrykk for å gå gjennom hvert element som er tilgjengelig i vårt Ember-modellobjekt. Husk at Ember-modellen er avledet fra kontrolleren, som er knyttet til malen, via Embers navnekonvensjoner.
Dette ville gjengi noe som ligner på:
Den utmerkede fordelen er Embers implisitte spesifikasjon av observatør, s som vil oppdatere dataene dine ved en oppdatering.
Hvis ditt betingede uttrykk må være mer komplekst, vil du opprette en beregnet eiendom. Dette lar deg lage en eiendom basert på en metode som kan bruke komplekse kodeforhold til dataene dine. La oss si at jeg bare ønsket å vise data som hadde tittelen "Tearable Cloth Simulation in JavaScript". Det er et par ting jeg trenger å sette opp:
App.TitleController = Ember.ObjectController.extend (titleMatch: function () return this.get ('title') === "Tearable Cloth Simulation i JavaScript"; .property ());
Ser vi på koden, er vi underklasse Ember.ObjectController
å opprette kontrolleren. Dette er kontrolleren som vil vikle hvert element som sløyfes i vår mal. Deretter lager vi en metode som kalles titleMatch
som bruker få()
metode for å trekke tilbake gjeldende tittel, sammenligne den med teksten jeg har definert, og returnere en boolsk. Til slutt, Ember eiendom() Metoden kalles for å definere titleMatch metode som en beregnet eiendom.
Når vi har dette på plass, oppdaterer vi malens #Hver
uttrykk for å representere hvert element med den nye kontrolleren vi opprettet. Dette gjøres ved å bruke itemController direktiv. En viktig ting å forstå er det itemController
er et nøkkelord i Ember ment å knytte en kontroller til elementer i en mal. Ikke forveksle det for en faktisk kontrollør navn (som jeg gjorde i utgangspunktet). Kontrollenavnet er tildelt til itemController
, som dette:
Igjen, navngi konvensjoner dikterer at når vi tilordner navn i maler, bruker vi små bokstaver. I dette tilfellet tilordner vi oss TitleController
til itemController
.
Nå, som hvert element er sløyfet over, den beregnede egenskapen, titleMatch
, brukes til å evaluere tittelen og vise data hvis den samsvarer.
Å lage dynamiske maler handler ikke bare om å spytte ut tekst. Det er tider når utseendet til brukergrensesnittet må påvirkes av data som behandles. Vise et bilde eller bygge en lenke er gode eksempler på dette.
Bindende data til et element krever bruk av spesielle Ember-hjelpere som hjelper til med å definere en attributts kontekst, samt sikre at attributter oppdateres riktig når data endres. For elementattributter, er BindAttr
Helper brukes til å fylle inn verdiene for et attributt. Hvis vi trengte å spesifisere nettadressen til et bilde dynamisk, bruker vi følgende syntaks:
Det samme kan gjøres for attributter som ikke mottar en verdi, for eksempel funksjonshemmet
:
I dette tilfellet, isAdminstrator
kan være en beregnet eiendom basert på en metode i kontrolleren, eller bare en vanlig objektegenskap som gir deg stor fleksibilitet ved å definere betingelsene for å deaktivere avmerkingsboksen. Denne fleksibiliteten overfører til å definere klassenavn også. Hvis jeg ønsket å bruke en betinget setning for å definere om en klasse skulle brukes på elementet mitt, kunne jeg bruke følgende kode:
Advarsel!
Avhengig av den boolske tilstanden vil mitt oppslag enten være:
Advarsel!
for en ekte
tilstand, eller:
Advarsel!
for en falsk
tilstand. Legg merke til at når jeg angav isUrgent
for klassen dasherer Ember navnet og gjorde klassen som er haster
. Hvis du foretrekker å spesifisere din egen klasse basert på resultatene, kan du bruke et betinget uttrykk som ligner på et ternært utsagn:
Dette kommer tilbake
som haster
ellernormal
for klassen, basert på den betingede verdien avisUrgent
.
Bli kjent med maler
Maler vil være grunnlaget for brukergrensesnittet ditt, så det vil være viktig at du bruker tid på å lese docs på både Ember og Handlebars-siden for å få en god følelse for deres generelle kraft. Selv om du ikke bruker Ember, er Handlebars et godt rammeverk for deg å bruke dag til dag, og verdt investeringen i å lære hvordan du bruker den.
Gabriel Manricks skrev en flott opplæring på håndtakene her på Nettuts + som du kan bruke for å komme opp i fart på rammen.