AEM 6.4 heeft het einde van de uitgebreide ondersteuning bereikt en deze documentatie wordt niet meer bijgewerkt. Raadpleeg voor meer informatie onze technische ondersteuningsperioden. Ondersteunde versies zoeken hier.
Bij het uitbreiden van OTB-gedrag is het belangrijk om upgrades in gedachten te houden. Pas altijd aanpassingen in de /apps folder en of bedekking bovenop de overeenkomstige knopen in de /libs folder toe of gebruik het gooien:resourceSuperType om uit het doosgedrag uit te breiden. Hoewel sommige wijzigingen nodig kunnen zijn om een nieuwe AEM te ondersteunen, mag de nieuwe versie uw aanpassingen niet overschrijven als deze praktijk wordt gevolgd.
Hierdoor kan de site een consistentere look en feel behouden en het onderhoud van de code vereenvoudigen. Wanneer een nieuw malplaatje nodig is, zorg ervoor om van een gedeeld basissjabloon uit te breiden zodat de globale vereisten zoals cliëntlib opneming op één plaats kunnen worden gecodeerd. Wanneer een nieuwe component nodig is, zoekt u naar mogelijkheden om zich uit te breiden van een bestaande component.
Door te bepalen welke componenten in elk parsys op de pagina kunnen worden omvat, kan de consistentie van de blik/het gevoel van de plaats worden gecontroleerd. Door de toegang tot het ontwerp op pagina's te beperken, kan "super auteurs"worden toegestaan om de toegestane componenten per pagina zonder ontwikkelaarsinterventie te wijzigen terwijl het ervoor zorgen dat de andere auteurs de collectieve normen volgen.
SOLID is een acroniem dat vijf architecturale principes beschrijft die zouden moeten worden nageleefd:
Het streven naar naleving van deze vijf beginselen moet resulteren in een systeem dat een strikte scheiding van zorgen heeft.
SOLID is een algemeen gebruikt concept in object-oriented programmering en elk element wordt uitgebreid besproken in de industrie literatuur.
Dit is slechts een korte samenvatting die wordt gepresenteerd voor bewustwording en u wordt aangespoord om meer vertrouwd te raken met deze concepten.
In het Robustness-beginsel staat dat we conservatief moeten zijn in wat we sturen, maar liberaal moeten zijn in wat we accepteren. Met andere woorden, wanneer we berichten naar derden sturen, moeten we ons volledig aan de specificaties houden, maar wanneer we berichten van derden ontvangen, moeten we niet-conforme berichten accepteren zolang de betekenis van het bericht duidelijk is.
Spikes en testcode maken integraal deel uit van elke Agile-software-implementatie, maar we willen ervoor zorgen dat ze niet in onze productiecode terechtkomen zonder het juiste niveau van toezicht. Daarom wordt aangeraden om punten in hun eigen module te maken.
Scripts voor gegevensmigratie, maar productiecode, worden doorgaans slechts eenmaal uitgevoerd bij de eerste keer dat een site wordt gestart. Zodra de site live is, wordt dit dus dode code. Om ervoor te zorgen dat we geen implementatiecode bouwen die afhankelijk is van de migratiescripts, moeten ze in hun eigen module worden geïmplementeerd. Hierdoor kunnen we deze code ook direct na het starten verwijderen en verwijderen, zodat dode code uit het systeem wordt verwijderd.
Apache heeft stijlconventies gepubliceerd op https://maven.apache.org/developers/conventions/code.html. Het is het beste om deze conventies te volgen, aangezien het voor nieuwe middelen gemakkelijker wordt om snel aan de slag te gaan.