Componentrichtlijnen component-guidelines

De Componenten van de Kernvolgen moderne implementatiepatronen die van de stichtingscomponenten vrij verschillend zijn.

Deze pagina verklaart deze patronen, en wanneer om hen te gebruiken om uw eigen authorable componenten te bouwen. De eerste sectie Algemene Patronen van de Componentis op om het even welk soort component van toepassing, terwijl de tweede sectie de Herbruikbare Patronen van de Componentop componenten van toepassing is die bedoeld zijn om over plaatsen of projecten, zoals de Componenten van de Kern bijvoorbeeld worden hergebruikt.

Algemene componentpatronen general-component-patterns

De richtlijnen in deze sectie worden geadviseerd voor om het even welk soort component, ongeacht of de component voor één enkel project specifiek is, of of de component bedoeld om over plaatsen of projecten wijd te worden hergebruikt.

Configureerbare componenten configurable-components

Componenten kunnen dialoogvensters met diverse opties hebben. Dit zou moeten worden leveraged om componenten flexibel en configureerbaar te maken, en het uitvoeren van veelvoudige componenten te vermijden die hoofdzakelijk variaties van elkaar zijn.

Als een draadframe of ontwerp variaties van vergelijkbare elementen bevat, moeten deze variaties gewoonlijk niet als verschillende componenten worden geïmplementeerd, maar als één component met opties om te kiezen tussen de variaties.

Om dit een stap verder te nemen, als de componenten over plaatsen of projecten worden hergebruikt, zie de pre-Configureerbare sectie van Mogelijkheden.

Scheiding van bezorgdheid separation-of-concerns

Het is doorgaans een goede gewoonte om de logica (of het model) van een component los te houden van de opmaaksjabloon (of weergave). Er zijn verscheidene manieren om dat te bereiken, nochtans geadviseerd te gebruiken Sling Modellenvoor de logica en Taal van het Malplaatje van de HTML(HTML) voor de prijsverhoging, als de Componenten van de Kern ook doen.

Sling Models is een reeks aantekeningen van Java om tot noodzakelijke variabelen van POJOs gemakkelijk toegang te hebben, en daarom een eenvoudige, krachtige, en efficiënte manier te bieden om Java logica voor componenten uit te voeren.

HTML is ontworpen als een veilige en eenvoudige sjabloontaal die is toegesneden op AEM. Het kan vele vormen van logica noemen, die het zeer flexibel maakt.

Herbruikbare componentpatronen reusable-component-patterns

De richtlijnen in deze sectie kunnen ook voor om het even welk soort component worden gebruikt, maar zij zijn het meest logisch voor componenten die bedoeld zijn om over plaatsen of projecten, zoals de Componenten van de Kern worden opnieuw gebruikt. Deze richtlijnen kunnen daarom worden genegeerd voor componenten die slechts op één enkele plaats of project worden gebruikt.

Vooraf configureerbare mogelijkheden pre-configurable-capabilities

Naast het dialoogvenster Bewerken dat wordt gebruikt door auteurs van pagina's, kunnen componenten ook een ontwerpdialoogvenster hebben waarin sjabloonauteurs ze vooraf kunnen configureren. De Redacteur van het Malplaatjestaat aan opstelling toe al deze pre-configuraties, die "Beleid"worden genoemd.

Om componenten zo herbruikbaar mogelijk te maken, zouden zij van zinvolle opties moeten worden voorzien om vooraf te vormen. Hierdoor kunnen functies van de componenten worden in- of uitgeschakeld, zodat deze voldoen aan de specifieke behoeften van verschillende sites.

Proxycomponentpatroon proxy-component-pattern

Aangezien elke inhoudsbron een sling:resourceType bezit heeft dat verwijzingen de component om het terug te geven, is het gewoonlijk goede praktijk om deze eigenschappen te hebben die aan plaats-specifieke componenten richten, in plaats van het richten aan componenten die door veelvoudige plaatsen worden gedeeld. Dit zal meer flexibiliteit aanbieden en inhoud het refactoring vermijden als één plaats een verschillend gedrag voor een component nodig heeft, omdat deze aanpassing dan op de plaats-specifieke component kan worden bereikt en niet de andere plaatsen zal beïnvloeden.

Nochtans, voor de project-specifieke componenten om het even welke code niet te dupliceren, zouden zij elk naar de gedeelde oudercomponent met het sling:resourceSuperType bezit moeten verwijzen. Deze project-specifieke componenten die het meest enkel naar oudercomponenten verwijzen worden genoemd "volmachtscomponenten". Proxycomponenten kunnen volledig leeg zijn als ze de functionaliteit volledig overnemen of als ze bepaalde aspecten van de component opnieuw kunnen definiëren.

Componentversie component-versioning

Componenten moeten in de loop der tijd volledig compatibel blijven, maar soms zijn wijzigingen die niet compatibel kunnen worden gehouden noodzakelijk. Één oplossing aan deze tegengestelde behoeften is component het versioning door een aantal in hun middel typepad toe te voegen, en in volledig - gekwalificeerde de klassennamen van Java van hun implementaties. Dit versieaantal vertegenwoordigt een belangrijke versie zoals die door wordt bepaald semantische versioning richtlijnen, die slechts voor veranderingen wordt verhoogd die niet achterwaarts-compatibel zijn.

Niet-compatibele wijzigingen in de volgende aspecten van componenten resulteren in een nieuwe versie ervan:

Voor verdere details, zie het 🔗 document van het Beleid van de Versioning in GitHub.

De versioning van de component leidt tot een vorm van contract die voor verbeteringen belangrijk is aangezien het verduidelijkt wanneer iets zou kunnen moeten worden verfrist. Zie ook de sectie Verenigbaarheid van de Verbetering van Aanpassingen, die verklaart welke overwegingen verschillende vormen van aanpassingen voor een verbetering vereisen.

Om pijnlijke inhoudsmigraties te vermijden, is het belangrijk om aan versioned componenten van inhoudsmiddelen nooit direct te richten. Als vuistregel geldt dat een sling:resourceType van de inhoud nooit een versienummer moet hebben, anders moet de inhoud bij het upgraden ook opnieuw worden bekeken. De beste manier om dit te vermijden is het hierboven beschreven Patroon van de Component van de Volmachtte volgen.

Modelinterfaces model-interfaces

Dit patroon gaat over de data-sly-use instructie van HTML om naar een Java-interface te wijzen, terwijl de implementatie van het Sling Model zich ook registreert bij het brontype van de component.

Wanneer gecombineerd met het hierboven beschreven Patroon van de Component van de Volmacht, deze vorm van dubbele bindende aanbiedingen na aardige uitbreidingspunten:

Alles samenvoegen putting-it-all-together

Hieronder volgt een overzicht van het volledige middeltype bindingsstructuur, die het voorbeeld van de Component van de Kern van de Titel neemt. Het illustreert hoe een plaats-specifieke volmachtscomponent toestaat om componentenversioning op te lossen, om te vermijden dat het inhoudsmiddel om het even welk versieaantal bevat. Het toont dan hoe het 2} dossiergebruik van de component title.html 🔗 HTML {aan de modelinterface, terwijl de implementatie aan de specifieke versie van de component door het Schipen Modelannotaties bindt.

Hieronder is een ander overzicht, dat niet de details van implementatiePOJO toont, maar openbaart hoe de bijbehorende malplaatjes en het beleidvan verwijzingen worden voorzien.

De eigenschap cq:allowedTemplates geeft aan welke sjablonen voor een site kunnen worden gebruikt en de eigenschap cq:template geeft aan elke pagina door wat de bijbehorende sjabloon is. Elke sjabloon bestaat uit de volgende drie delen:

Projectarchetype AEM aem-project-archetype

het Archieftype van het Project van de AEMleidt tot een minimaal project van Adobe Experience Manager als uitgangspunt voor uw eigen projecten, met inbegrip van een voorbeeld van douaneHTML componenten met SlingModels voor de logica en juiste implementatie van de Componenten van de Kern met het geadviseerde volmachtspatroon.

Lees daarna: