Inhoudsarchitectuur

Volg David's model

David's Model werd jaren geleden geschreven door David Nuescheler, maar de ideeën zijn vandaag de dag van kracht. De belangrijkste uitgangspunten van David’s Model zijn:

• Gegevens komen als eerste, structuur later. Misschien.
• Geef de hiërarchie van de inhoud aan en laat deze niet gebeuren.
• Werkruimten zijn bedoeld voor clone(), merge(), en update().
• Wees op dezelfde naam voorbereid.
• Verwijzingen worden als schadelijk beschouwd.
• Bestanden zijn bestanden.
• Id's zijn slecht.

Het model van David is te vinden op de Jackrabbit wiki op https://wiki.apache.org/jackrabbit/DavidsModel.

Alles is inhoud

Alles moet in de gegevensopslagruimte worden opgeslagen in plaats van te vertrouwen op afzonderlijke gegevensbronnen van derden, zoals databases. Dit geldt voor geschreven inhoud, binaire gegevens zoals afbeeldingen, code, configuraties, enz. Hierdoor kunnen we één set API's gebruiken om alle inhoud te beheren en de promotie van deze inhoud via replicatie te beheren. We krijgen ook één bron van back-up, registratie, enzovoort.

Het ontwerpbeginsel "inhoudsmodel eerst" gebruiken

Wanneer u een nieuwe functie maakt, begint u altijd eerst met het ontwerpen van de JCR-inhoudsstructuur. Daarna leest u de inhoud en schrijft u deze in de standaardservlets. Dit zal u toestaan om ervoor te zorgen dat uw implementatie goed met uit de doos controlemechanismen van de toegangscontrole werkt en u toestaan om het produceren van onnodige CRUD-Stijl servlets te vermijden.

Wees RESTful

De servers zouden op resourceTypes in plaats van wegen moeten worden bepaald. Dit maakt het mogelijk om de toegangscontroles van het JCR te gebruiken, aan de principes van het REST te houden, en de middel en middeloplosser te gebruiken die aan ons in het verzoek worden verstrekt. Hierdoor kunnen we ook de scripts wijzigen die URL's renderen aan de serverzijde zonder dat we URL's hoeven te wijzigen aan de clientzijde, terwijl implementatiedetails aan de serverzijde voor extra beveiliging worden verborgen.

Nieuwe knooppunttypen niet definiëren

De types van knoop werken op een laag niveau in de infrastructuurlaag en de meeste vereisten kunnen worden voldaan door een sling te gebruiken:resourceType dat aan een nt:unStructured, eik:UnStructured, sling:Omslag of cq:het knooppunttype van de Pagina wordt toegewezen. De types van knoop komen aan schema in de bewaarplaats overeen en het veranderen van knooptypes kan zeer duur onderaan de weg zijn.

Naleving van naamgevingsconventies in het JCR

Het naleven van noemende overeenkomsten zal consistentie aan uw codebasis toevoegen, verminderend het veelvoud van onvolkomenheden en verhoogt de snelheid van ontwikkelaars die in het systeem werken. Adobe gebruikt de volgende conventies bij het ontwikkelen van AEM:

• Node-namen

  • Alles kleine letters
  • Woordscheiding met afbreekstreepjes

• Namen van eigenschappen

  • Camelhoofdletter, beginnend met een kleine letter

• Componenten (JSP/HTML)

  • Alles kleine letters
  • Woordscheiding met afbreekstreepjes

Business.Adobe.com-bronnen

Multichannel Communication Automated Onboarding Style System Personalized Experiences Content As A Service Digital Signage