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, markdown en Google Doc/Word. Wij roepen 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 standaardinhoud, hebben wij een concept pagina secties, die door horizontale lijnen worden gescheiden 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.

Naast dat is er concept blokken die als lijst met een rubriek als eerste rij worden ontworpen die het type van blok identificeert. 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 tot het gemakkelijk toegang hebben gebruikend de meningsbron eigenschap en een blik hebben bij de prijsverhoging van de pagina u momenteel leest.

De JavaScript-bibliotheek die in scripts.js wordt gebruikt, neemt de markering en verbetert deze in een DOM dat vervolgens voor de meeste ontwikkelingstaken wordt gebruikt, met name 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.

Het bestaat voornamelijk uit de introductie van een wrapper <div> voor blokken en standaardinhoud en het dynamisch toevoegen van extra handige CSS-klassen en gegevenskenmerken die worden gebruikt door de AEM-bloklader.

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 met de naam Section Metadata bevatten. Dit levert gegevenskenmerken op voor een sectie. De namen van de gegevenskenmerken kunnen door de auteurs worden gekozen en de enige bekende eigenschap voor sectiemetagegevens is Style die wordt 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 die wordt gedeeld tussen Word-documenten, Google Docs, markeringen en HTML. Er zijn bijvoorbeeld rubrieken van verschillende niveaus (bijv. <h1> - <h6> ), afbeeldingen, koppelingen, lijsten ( <ul> , <ol> ), accenten (<em> , <strong> ), enz.

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 hen dan in de prijsverhoging van 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 eenvoudige <img> -tag wordt een volledige <picture> -tag 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 dat 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.

De JavaScript wordt geladen als een Module (ESM) en exporteert een standaardfunctie die wordt uitgevoerd als onderdeel van het laden van blokken.

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 Blok van Kolommen. 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 geneste <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 -blokken die op elke pagina van een site aanwezig moeten zijn, zijn hiervan een goed voorbeeld.

Blokopties

Als u een blok nodig hebt om te kijken of zich lichtjes verschillend te gedragen gebaseerd op bepaalde omstandigheden, maar niet verschillend genoeg om een nieuw blok op zich te worden, kunt u auteurs blokopties aan blokken tussen haakjes toevoegen. Met deze opties voegt u gewijzigde klassen toe aan het blok. Columns (wide) in een tabelkoptekst genereert bijvoorbeeld de volgende markering.

<div class=”columns wide”>

Blokopties kunnen ook meerdere woorden bevatten. Columns (super wide) wordt bijvoorbeeld samengevoegd met afbreekstreepjes.

<div class=”columns super-wide”>

Als blokopties gescheiden zijn door komma's, zoals Columns (dark, wide) , worden ze 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 auto die blokkeert. 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 eigenschap template . 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 dat de auteur een blok samenstelt dat al die informatie bevat, zou een autoblok (bijvoorbeeld artikel-kopbalblok) programmatically aan de pagina worden toegevoegd die op <h1>, het eerste beeld, de blogauteur, en de meta-gegevens van de publicatiedatum wordt gebaseerd.

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 naar een YouTube-video maakt door gewoon een koppeling op te nemen, terwijl de ontwikkelaar alle code voor de video inline wilt insluiten in een embed -blok.

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.