AEM Design Doc
Status of design doc:
Authors: Kris Charbonneau
Reviewers: Marco Flores, Mike Pond, Paul Craig
Content management systems create an easy way for our content creators to add content to our sites without having to touch any code. This design document will outline how we plan to implement AEM alongside our application.
Looking at our user story
As a content designer, I would like to be able to use a CMS to manage the site content, so that I don’t have to ask the devs to make changes all the time or learn git to administer the changes myself.
We want to make adding content as accessible as possible for our content creators so that when the creators make revisions to the content fragment in AEM, the changes show up on our application.
- Provide a means for our content creators to easily add content to our site
- Content added via AEM's interface immediately shows up on our site
- AEM will strictly be used to add content to an already existing application. We will not be building out full pages with AEM.
What are the high level checkpoints and when do we want to achieve them
Start Date: [ some date ]
Milestone 1 - [ goal ] [date]
Milestone 2 - [ goal ] [date]
.
.
.
End Date: [ some date ]
The existing solution for adding new data is our own API which simply grabs the data from a local JSON file. At the time of writing this, we currently only have this functionality set up for the topic boxes on our landing page. Going forward this will still be used for testing for devs, however (Local) will be appended to the content to differentiate between the two data sources, as seen here:
The proposed solution here is to use content fragments. Content fragments are the AEM answer to using a Headless CMS. You can define a content fragment model, create content fragments, and then use a public JSON endpoint to retrieve them.
A content fragment model uses a drag and drop interface to create a model for some data type. So, if you wanted to create an event content model, you might use: “title”, “description”, “location”, “time”, etc. At the time of writing this document, we've only defined a content model for our topic boxes, which you can see below:
For this content model, we've defined a title, a language dropdown field with the choice of English or French, a description, a link (ie /having-a-baby), and tags which are for the "find information about" labels on our topic boxes.
Once the content model is created, you can create content fragments using this model as a template. Using the Having a Baby topic box as an example, below is how it would look to create the fragment:
And this is the result we should see on our webpage:
And how our content fragments look in AEM once created:
All of this data can then be retrieved from a JSON endpoint to be used in our topic boxes on our live domain.
The below diagram gives an idea of what the proposed flow will look like:
Unit tests can be written to mock a fetch and ensure the data that is returned is as expected.
- Will require devs to implement a way to handle data whenever new fragments are needed or created in order for it to be properly implemented
- If someone new is assigned to the project, they will need to take mandatory AEM training prior to being given access to their account
- Currently, when you try to login to AEM you're met with a security certificate issue
- Using the AEM editor requires you to be on the ESDC network but the published content is publicly available
- How will we handle filtering the data by language? We only have a single JSON endpoint so we'll have to look into how to properly handle that data coming in.
- As it stands right now the code is only deployed when
mainis updated. If content is added or updated through AEM, should that trigger a new build? What is the mechanism there?