Markeringen, secties, blokken en automatische blokkering
Voor het ontwerpen van websites en het maken van functionaliteit gebruiken ontwikkelaars de opmaak en DOM die dynamisch worden gerenderd op basis van de inhoud. De opmaak en DOM zijn zodanig samengesteld dat ze flexibel kunnen worden bewerkt en opgemaakt. Tegelijkertijd biedt de toepassing functionaliteit buiten de box, zodat de ontwikkelaar zich geen zorgen hoeft te maken over een aantal aspecten van moderne websites.
Structuur van een document
Het belangrijkste aspect bij het structureren van een document is het eenvoudig en intuïtief maken voor auteurs die de inhoud zullen leveren.
Dit betekent dat het ten zeerste wordt aanbevolen om auteurs zeer vroeg bij het proces te betrekken. In veel gevallen is het een goede gewoonte om auteurs de inhoud die nodig is op een pagina te laten zetten in een Google Doc of Word-document zonder dat ze een idee hebben van blokken en secties. Probeer dan kleine structurele wijzigingen aan te brengen en introduceer secties en blokken alleen waar dat nodig is.
Een document volgt de volgende structuur in het abstract.
Een pagina zoals geschreven in Word of een document van Google Doc gebruikt het goed begrepen semantische model zoals rubrieken, lichaamstekst, lijsten, beelden, verbindingen, enz. die wordt gedeeld tussen HTML, markering, en Google Doc/Word. We noemen dit standaardinhoud. In een ideale situatie zou zo veel mogelijk van de geschreven inhoud als standaard inhoud worden achtergelaten, aangezien dit de natuurlijke manier is voor auteurs om documenten te behandelen.
Naast de standaardinhoud hebben we een concept van pagina secties, gescheiden door horizontale lijnen of --- om bepaalde elementen van een pagina samen te groeperen. Er kunnen semantische en ontwerpredenen zijn om inhoud samen te groeperen. Een eenvoudig geval kan zijn dat een sectie van een pagina een andere achtergrondkleur heeft.
Daarnaast bestaat er een concept van blokken die zijn geschreven als een tabel met een kop als de eerste rij die het type blok aangeeft. Dit concept is de eenvoudigste manier om uw code samen te stellen.
Secties kunnen meerdere blokken bevatten. Blokken mogen nooit worden genest, omdat het veel moeite kost om te gebruiken voor auteurs.
DOM vs. opmaak
AEM maakt een heldere en gemakkelijk leesbare semantische markering op basis van de inhoud die eraan wordt geleverd. U kunt deze gemakkelijk openen met de weergavebron en bekijk de markering van de pagina die u momenteel leest.
De JavaScript-bibliotheek die in scripts.js neemt de prijsverhoging en verbetert het in DOM dat dan voor de meeste ontwikkelingstaken, specifiek wordt gebruikt om blokken te bouwen. Als u een DOM wilt maken waarmee u eenvoudig kunt werken voor aangepaste projectcode, kunt u dit het beste zien als een proces dat uit twee stappen bestaat.
In de eerste stap maken we de markering met secties, blokken en standaardinhoud die er ongeveer zo uitziet.
In de tweede stap wordt de bovenstaande markering uitgebreid naar het volgende voorbeeld-DOM, dat vervolgens kan worden gebruikt voor het opmaken en toevoegen van functionaliteit. De verschillen tussen de prijsverhoging die van de server wordt geleverd en het verhoogde DOM dat voor de meeste ontwikkelingstaken wordt gebruikt worden hieronder benadrukt.
Bestaat voornamelijk uit het aanbrengen van een onmiddellijke verpakking <div> voor blokken en standaardinhoud en dynamisch extra nuttige CSS-klassen en gegevenskenmerken toevoegen die door de AEM bloklader worden gebruikt.
Secties
Secties zijn een manier om standaardinhoud en -blokken door de auteur te groeperen. De meeste einden van tijdsecties worden geïntroduceerd op basis van visuele verschillen tussen secties, zoals een verschillende achtergrondkleur voor een deel van een pagina.
Vanuit ontwikkelingsperspectief is er meestal niet veel interactie met secties die verder gaan dan CSS-opmaak.
Secties kunnen een speciaal blok bevatten met de naam Section Metadata, wat resulteert in gegevenskenmerken voor een sectie. De namen van de gegevenskenmerken kunnen door de auteurs worden gekozen en de enige bekende eigenschap voor sectiemetagegevens is Style die worden omgezet in extra CSS-klassen die worden toegevoegd aan het omvattende sectie-element.
Blokken en standaardinhoud worden altijd ondergebracht in een sectie, zelfs als de auteur niet specifiek sectie-einden invoert.
Standaardinhoud
Er is een breed scala aan semantiek dat wordt gedeeld tussen Word-documenten, Google Docs, markdown en HTML. Er zijn bijvoorbeeld rubrieken van verschillende niveaus (bijv. <h1> - <h6>), afbeeldingen, koppelingen, lijsten (<ul>, <ol>), accentueren (<em>, <strong>).
We maken gebruik van het intuïtieve inzicht dat auteurs hebben in hoe ze deze semantiek moeten gebruiken in de tools die ze kennen (bijvoorbeeld Word/Google (docs) en wijst die aan prijsdaling in kaart en geeft dan hen in de prijsverhoging van de HTML terug.
Alle toewijzingen moeten relatief eenvoudig en intuïtief zijn voor de ontwikkelaar. Een gebied waar we iets verder gaan dan de eenvoudigste vertaling is het verwerken van afbeeldingen. In plaats van een eenvoudig <img> tag, een volledige <picture> -tag wordt weergegeven met een aantal verschillende resoluties die nodig zijn voor weergave op mobiele en desktopapparaten en verschillende indelingen voor moderne browsers die webpagina's en oudere browsers ondersteunen die dit niet doen.
Blokken
De meeste projectspecifieke CSS en JavaScript leven in blokken. Auteurs maken blokken in hun documenten en ontwikkelaars schrijven de corresponderende code die de blokken met CSS opmaakt en/of het DOM decoreert om de opmaak van een blok te nemen en deze om te zetten in de structuur die nodig of handig is voor de gewenste opmaak en functionaliteit.
De bloknaam wordt gebruikt als zowel de mapnaam van een blok als de bestandsnaam van de CSS- en JavaScript-bestanden die door de blokloader worden geladen wanneer een blok op een pagina wordt gebruikt. De bloknaam wordt ook gebruikt als de CSS-klassenaam op het blok voor intuïtieve opmaak.
JavaScript wordt geladen als Module (ESM) en voert een standaardfunctie uit die als deel van het blokladen wordt uitgevoerd.
Alle CSS op blokniveau moet binnen het bereik van het blok vallen om ervoor te zorgen dat er geen bijwerkingen zijn voor andere delen van het project. Dit betekent dat alle kiezers in een blok vooraf moeten worden geplaatst met de corresponderende blokklasse. In bepaalde gevallen is het ook zinvol om voor de kiezer de omslag van het blok of de bevattende sectie te gebruiken.
Er is een evenwicht tussen DOM-manipulatie in JavaScript en complexiteit van de CSS-kiezers. Complexe, broze CSS-kiezers worden niet aangeraden en het toevoegen van klassen aan elk element maakt de code complexer en negeert de semantiek van elementen.
Een van de belangrijkste uitgangspunten van een project is om dingen eenvoudig en intuïtief te houden voor auteurs. Door gecompliceerde blokken wordt het moeilijk om inhoud te ontwerpen. Het is dus belangrijk dat ontwikkelaars de complexiteit van het omzetten van een intuïtieve ontwerpervaring in het DOM opnemen die nodig is voor lay-out- of toepassingslogica. Het is vaak verleidelijk om ingewikkeldheid aan de auteur te delegeren. In plaats daarvan moeten ontwikkelaars ervoor zorgen dat blokken niet lastig te maken worden voor auteurs. Een auteur moet altijd een blok kunnen kopiëren/plakken en intuïtief begrijpen waar het om gaat.
Een eenvoudig voorbeeld is het Kolomblok. Er worden extra klassen toegevoegd in JavaScript op basis van het aantal kolommen in de desbetreffende instantie die door de auteur is gemaakt. Hierdoor kan het programma de flexibele opmaak van inhoud in twee kolommen gebruiken in vergelijking met drie kolommen.
Blokken kunnen zeer eenvoudig zijn of volledige toepassingscomponenten of widgets bevatten en de ontwikkelaar de mogelijkheid bieden om hun codebase te componeren in kleine stukjes code die eenvoudig kunnen worden beheerd en waar nodig op de webpagina's kunnen worden geladen.
De inhoud van een blok wordt in de markering gerenderd als genest <div> -tags voor de rijen en kolommen die de auteur heeft ingevoerd. In het eenvoudigste geval heeft een blok slechts één cel.
<div class=”blockname”>
<div>
<div>
<p>Hello, World.</p>
</div>
</div>
</div>
Auteurs kunnen blokken ad hoc aan hun pagina's toevoegen door eenvoudig een lijst met de bloknaam in de eerste rij of lijstrubriek toe te voegen. Sommige blokken worden ook automatisch geladen. header en footer blokkeringen die op elke pagina van een site aanwezig moeten zijn, zijn daarvan een goed voorbeeld.
Blokopties
Als u een blok nodig hebt om er iets anders uit te zien of te gedragen op basis van bepaalde omstandigheden, maar niet anders genoeg om een nieuw blok op zich te worden, kunt u auteurs toestaan om blokopties aan blokken tussen haakjes. Met deze opties voegt u gewijzigde klassen toe aan het blok. Bijvoorbeeld Columns (wide) in een tabelkop wordt de volgende markering gegenereerd.
<div class=”columns wide”>
Blokopties kunnen ook meerdere woorden bevatten. Bijvoorbeeld Columns (super wide) worden samengevoegd met afbreekstreepjes.
<div class=”columns super-wide”>
Als blokopties door komma's worden gescheiden, zoals Columns (dark, wide)worden toegevoegd als afzonderlijke klassen.
<div class=”columns dark wide”>
Automatisch blokkeren
In een ideaal scenario wordt de meeste inhoud buiten blokken geschreven, aangezien het introduceren van lijsten in een document het moeilijker maakt om te lezen en uit te geven. Omgekeerd bieden blokken ontwikkelaars een geweldig mechanisme om hun code te organiseren.
Een vaak gebruikt mechanisme om het beste van beide werelden te krijgen wordt genoemd automatisch blokkeren. Met Automatisch blokkeren worden standaardinhoud en metagegevens omgezet in blokken zonder dat de auteur ze fysiek moet maken. Automatisch blokkeren gebeurt zeer vroeg in het paginaversieringsproces voordat blokken worden geladen. Dit is een praktijk die programmatically de DOM-structuur van een blok maakt zoals deze als opmaakcode van de server zou worden weergegeven.
Automatisch blokkeren wordt vaak gebruikt in combinatie met metagegevens, met name de template eigenschap. Als pagina's een gemeenschappelijke sjabloon hebben, wat betekent dat ze een bepaald paginaontwerp of een bepaalde functionaliteit delen, is dit doorgaans een goede gelegenheid om automatisch te blokkeren.
Een goed voorbeeld is een artikelkop van een blogbericht. Het kan informatie bevatten over de auteur, de titel van het blogbericht, een hoofdafbeelding en de publicatiedatum. In plaats van de auteur een blok te laten samenstellen dat al die informatie bevat, zou een autoblok (bijvoorbeeld artikel-kopbalblok) programmatically aan de pagina worden toegevoegd die op \ wordt gebaseerd<h1>, de eerste afbeelding, de blogauteur en metagegevens over de publicatiedatum.
Hierdoor kan de auteur van de inhoud de informatie op de normale plaats houden, de documentstructuur buiten een blok. Tegelijkertijd kan de ontwikkelaar alle lay-out- en opmaakgegevens in een blok bewaren.
Een andere veelgebruikte manier is om blokken rond koppelingen in een document te plaatsen. Een goed voorbeeld hiervan is een auteur die een koppeling maakt naar een YouTube-video door eenvoudig een koppeling op te nemen, terwijl de ontwikkelaar alle code voor de video inline wilt houden embed blokkeren.
Dit mechanisme kan ook worden gebruikt als een flexibele manier om zowel externe toepassingen als interne verwijzingen naar video, inhoudsfragmenten, modals, formulieren en andere toepassingselementen op te nemen.
De code voor uw projecten blokkeert automatisch levens in buildAutoBlocks() in uw scripts.js.
Zie de volgende voorbeelden van automatische blokkering.