In mijn vorige zelfstudie heb ik gerefereerd over hoe te gebruiken Ember.Object
om uw modellen te definiëren en met datasets te werken. In dit gedeelte gaan we dieper in op hoe Ember het Handlebars-sjabloonkader gebruikt om de gebruikersinterface van uw app te definiëren.
De meeste ontwikkelaars aan de server zijn eraan gewend om sjablonen te gebruiken om markeringen te definiëren die tijdens de vlucht dynamisch worden gevuld. Als je ooit ASP.NET, ColdFusion, PHP of Rails hebt gebruikt, is het vrijwel zeker dat je weet waar ik het over heb.
JavaScript Aan de client-zijde is de laatste tijd echt van de grond gekomen, vooral vanwege de focus op het bouwen van meer desktopachtige ervaringen. Dit betekent dat meer van de verwerking gebeurt aan de kant van de klant, waarbij de gegevens voornamelijk worden getrokken via API-aanvragen op de server.
Ik herinner me dat ik enige tijd geleden schreef over client-side templates toen de jQuery Template-plugin voor het eerst werd uitgebracht. Bijna drie jaar later is het nog steeds de meest gelezen post op mijn blog, die laat zien hoe de belangstelling voor klantgerichtheid is toegenomen. Sindsdien zijn een aantal andere frameworks vrijgegeven, die rijke functies en ondersteunende gemeenschappen bieden. Stuur is een van de meer populaire opties en het raamwerk dat door het Ember-project is gekozen om zijn behoeften aan sjabloneren te versterken. Dit is logisch omdat Handlerbars is gemaakt door Ember.js, mede-oprichter en kernteamlid, Yehuda Katz. Merk echter op dat ik niet van plan ben om vergelijkingen te maken tussen templating frameworks en ik zal me strikt richten op Handelbars, omdat Ember.js dit standaard gebruikt..
In de vorige artikelen toonde ik een aantal heel basale sjablonen in de code:
Twee dingen die opvallen, zijn de typeaangifte voor de scripttag en de accolades die fungeren als scheidingstekens voor de expressies waarop Handlebars zullen reageren. Dit is een zeer typische syntaxis die ik binnenkort in meer detail zal bespreken en die u consequent zult gebruiken bij het maken van Ember-sjablonen.
Ondanks het feit dat Handlebars een speciale syntaxis gebruikt, werk je aan het einde van de dag voornamelijk met standaard HTML-markeringen. Stuur dient om inhoud in deze opmaak te injecteren om gegevens aan de gebruiker te geven. Dit doet het door de gescheiden uitdrukkingen te ontleden en deze te vervangen door de gegevens die u hebt gevraagd aan het Stuur om mee te werken. In het geval van Sintel, stuurt Stuur de haken en gebruikt Ember ze. Die gegevens zijn meestal afkomstig van uw controller (onthoud dat controllers dienen als interface voor uw modellen).
Het eerste dat een sjabloon nodig heeft, is een scripttagdefinitie. De meesten van jullie hebben waarschijnlijk scripttags gedefinieerd om je JavaScript-bibliotheek te laden. In feite heb je dit al gedaan om Stuur in je Ember-project te laden:
Er is een klein verschil met het gebruik om een sjabloon te definiëren. Eerst specificeren we een type
kenmerk van "tekst / x-stuur". Deze type
wordt genegeerd door de browser maar laat de tekst beschikbaar voor inspectie en maakt het voor Ember mogelijk om sjablonen in de app te identificeren. Bovendien gebruikt Ember een gegevenskenmerk genaamd "data-template-name" dat door Ember kan worden gebruikt om specifieke delen van uw applicatie aan een sjabloon te koppelen. De volgende verklaring definieert bijvoorbeeld een sjabloon met de naam "werknemer":
Wanneer uw toepassing start, scant Sintel de DOM voor Type = "text / x-stuur
, compileert de sjablonen die worden gevonden en slaat deze op in een eigenschap van het genoemde Ember-object Ember.TEMPLATES
die het gebruikt om erachter te komen wat te renderen voor een bepaalde route. Dit is de reden waarom het volgen van de naamgevingsconventies van Ember zo belangrijk is. In het bovenstaande voorbeeld wordt deze sjabloon automatisch gekoppeld aan de werknemersroute en controller die u in uw toepassing hebt gemaakt. Nogmaals, ik kan niet genoeg benadrukken hoe deze naamgevingsconventies je ontwikkeling veel gemakkelijker zullen maken.
Ember is afhankelijk van URL's om te bepalen welke bronnen moeten worden gebruikt en welke sjablonen moeten worden weergegeven. Laten we ons voorstellen dat je een profielpagina had met de URL "/ profiel". Je zou een resource hebben, genaamd profiel
dat zou specifieke bronnen laden voor die URL (zoals een routevoorwerp) en je zou ook een sjabloon met dezelfde naam hebben. We hebben middelen en routevoorwerpen besproken in deel 2 van mijn Ember-serie, dus als je niet zeker weet wat ik bespreek, kun je hier terugkomen om jezelf op te frissen.
Wanneer u die URL bezoekt, weet Ember dat deze deze bronnen moet laden en de sjabloon moet analyseren die u hebt gedefinieerd. Het doet dit via zijn naamconventies, wetende dat omdat je naar "/ profile" ging, het de bronnen moet laden die zijn gedefinieerd in de profiel
, en render de sjabloon, genaamd data-template-name = "profile"
.
Als u de naamgevingsconventies opnieuw overziet, ziet u dat route, controller en sjabloon allemaal aan dezelfde URL-naam zijn gekoppeld, met de uitzondering dat de sjabloon in kleine letters is gespeld. Op deze manier kan Ember alles achter de schermen beheren zonder dat u veel van de bedrading hoeft op te laden.
Het is ook belangrijk om op te merken dat, als u een sjabloon declareert zonder een data-template-naam
attribuut, zal Ember aannemen dat dit de sjabloon met toepassingsbereik is, die doorgaans wordt gebruikt als een sjabloon voor het maken van elementen van de gebruikersinterface, zoals kop- en voetteksten en navigatie. En als u niet expliciet een sjabloon voor een toepassing of zelfs een bron definieert (bijvoorbeeld voor een URL), doet Ember dat automatisch voor u om de stabiliteit en consistentie in uw app te waarborgen.
De volgende stap is om uw markeringen en de gescheiden uitdrukkingen op te nemen die u zult gebruiken om uw gegevens te vertegenwoordigen. Uitdrukkingen worden gescheiden, via dubbele accolades zodat ze gemakkelijk kunnen worden geïdentificeerd en geparseerd met gegevens die worden doorgegeven vanaf uw controller. Hier is een voorbeeld:
In dit geval, de Voornaam
en achternaam
expressies worden geparseerd door Sintel en vervangen door werkelijke gegevens. Bovendien zet Ember waarnemers op zodat uw sjabloon automatisch wordt bijgewerkt en de updates worden weergegeven aan de gebruiker van uw app wanneer uw gegevens worden gewijzigd..
Tot nu toe heb ik je een heel eenvoudig voorbeeld laten zien, maar de afhaalmaaltijd is dat:
Dit biedt veel flexibiliteit bij het structureren van uw gebruikersinterface. Laten we verder kijken naar de beschikbare functies.
Onthoud dat Ember het stuur gebruikt, dus je hebt hier toegang tot de volledige breedte van expressies. Voorwaardelijke uitdrukkingen zijn een must om bijna alles nuttig te maken; Stuur biedt een flink aantal opties.
Laten we zeggen dat ik een JSON-dataset had die er zo uitzag:
"items": ["title": "Tearable Cloth Simulation in JavaScript", "url": "http://codepen.io/stuffit/pen/KrAwx", "id": 5592679, "commentCount": 20, "punten": 127, "postedAgo": "1 uur geleden", "postedBy": "NathanKP", "title": "Netflix nu groter dan HBO", "url": "http://qz.com / 77067 / netflix-now-bigger-than-hbo / "," id ": 5592403," commentCount ": 68," points ": 96," postedAgo ":" 2 uur geleden "," postedBy ":" edouard1234567 "
Als ik ervoor wilde zorgen dat het titel
gegevens beschikbaar zijn, ik zou een voorwaardelijke "als" -instructie kunnen toevoegen met behulp van de #als
uitdrukking:
#if item.title
Dit controleert om te zien of titel van het item
is niet ongedefinieerd en gaat door met het verwerken van de volgende uitdrukkingen voor de titel
, postedAgo
en Gepost door
gegevensuitdrukkingen.
Aangezien deze dataset meer dan één "record" bevat, is het veilig om aan te nemen dat we waarschijnlijk elk element van willen doorlopen item
. Dat is waar de #elk
expressie komt om de hoek kijken. Hiermee kunt u een lijst met objecten opsommen. Dus nogmaals, in gedachten houdend dat sjablonen een combinatie zijn van markup en stuur expressies, kunnen we de #elk
expressie om door elk item te bladeren dat beschikbaar is in ons Ember-modelobject. Vergeet niet dat het Ember-model is afgeleid van de controller, die is gekoppeld aan de sjabloon, via de naamgevingsconventies van Ember.
Dit zou iets opleveren dat lijkt op:
Het duidelijke voordeel is Ember's impliciete specificatie van waarnemer, die uw gegevens bijwerkt tijdens een update.
Als uw voorwaardelijke expressie complexer moet zijn, wilt u een berekende eigenschap maken. Hiermee kunt u een eigenschap maken op basis van een methode die complexe codevoorwaarden op uw gegevens kan toepassen. Laten we zeggen dat ik alleen gegevens wilde weergeven die de titel "Tearable Cloth Simulation in JavaScript" hadden. Er zijn een aantal dingen die ik moet instellen:
App.TitleController = Ember.ObjectController.extend (titleMatch: function () return this.get ('title') === "Tearable Cloth Simulation in JavaScript"; .property ());
Als we naar de code kijken, subclasseren we Ember.ObjectController
om de controller te maken. Dit is de controller die elk item dat wordt omgeleid in onze sjabloon verpakt. Vervolgens maken we een methode, genaamd titleMatch
welke de krijgen()
methode om de huidige titel terug te trekken, te vergelijken met de tekst die ik heb gedefinieerd en een booleaanse waarde te retourneren. Ten slotte, de Sintel eigendom() methode wordt aangeroepen om de titleMatch methode als een berekende eigenschap.
Zodra we dit hebben ingevoerd, werken we de sjablonen bij #elk
expressie om elk item te vertegenwoordigen met de nieuwe controller die we hebben gemaakt. Dit wordt gedaan met behulp van de itemController richtlijn. Een belangrijk ding om te begrijpen is dat itemController
is een sleutelzin in Sintel bedoeld om een controller te associëren met items van een sjabloon. Verwar het niet voor de naam van een echte controller (zoals ik aanvankelijk deed). De naam van de controller is toegewezen aan itemController
, zoals dit:
Nogmaals, namenconventies dicteren dat we bij het toewijzen van namen in sjablonen kleine letters gebruiken. In dit geval zijn we aan het toewijzen TitleController
naar itemController
.
Nu, terwijl elk item wordt doorgelust, de berekende eigenschap, titleMatch
, wordt gebruikt om de titel te evalueren en gegevens weer te geven als deze overeenkomt.
Het maken van dynamische sjablonen gaat niet alleen om het uitspugen van tekst. Soms moet het uiterlijk van de gebruikersinterface worden beïnvloed door de gegevens die worden verwerkt. Een afbeelding weergeven of een link opbouwen zijn daar goede voorbeelden van.
Het binden van gegevens aan een element vereist het gebruik van speciale Ember-helpers die helpen bij het definiëren van de context van een attribuut, en ervoor zorgen dat de attributen juist worden bijgewerkt wanneer gegevens veranderen. Voor elementattributen, de BindAttr
helper wordt gebruikt om de waarden voor een attribuut in te vullen. Als we de URL van een afbeelding dynamisch moeten opgeven, gebruiken we de volgende syntaxis:
Hetzelfde kan worden gedaan voor attributen die geen waarde ontvangen, zoals invalide
:
In dit geval, isAdminstrator
kan een berekende eigenschap zijn gebaseerd op een methode in de controller of gewoon een normale objecteigenschap die u veel flexibiliteit geeft bij het definiëren van de voorwaarden voor het uitschakelen van het selectievakje. Deze flexibiliteit draagt ook bij aan het definiëren van klassenamen. Als ik een voorwaardelijke verklaring wilde gebruiken om te definiëren of een klasse zou moeten worden toegepast op mijn element, zou ik de volgende code kunnen gebruiken:
Waarschuwing!
Afhankelijk van de booleaanse status zou mijn opmaak ofwel zijn:
Waarschuwing!
voor een waar
voorwaarde, of:
Waarschuwing!
voor een vals
staat. Merk op dat toen ik specificeerde is urgent
voor de klas nam Sintel de naam van de klas en maakte de klas zo is urgent
. Als u liever uw eigen klasse opgeeft op basis van de resultaten, kunt u een voorwaardelijke uitdrukking gebruiken die lijkt op een ternaire instructie:
Dit komt terug
dringend
ofnormaal
voor de klasse, op basis van de voorwaardelijke waarde vanis urgent
.
Maak kennis met sjablonen
Sjablonen vormen de basis van uw gebruikersinterface, dus het zal belangrijk zijn dat u tijd besteedt aan het lezen van de documenten op zowel de site van Ember en Handlebars om een goed gevoel te krijgen voor hun algehele vermogen. Zelfs als u geen gebruik maakt van Ember, is Handlebars een geweldig kader voor u om dagelijks te gebruiken, en de investering waard om te leren hoe het te gebruiken.
Gabriel Manricks heeft hier een geweldige tutorial over Handlebars op Nettuts + geschreven die je kunt gebruiken om op snelheid te komen.