In publish-mode AEM is able to generate any html you want. But for authoring-mode, AEM is shipped with many out-of-the-box editors. And they do some assumption about the html. So either follow those assumptions, or you have to customize those editors or create your own ones. The later one causes a lot of effort, and less experienced AEM developers will fail.
AEM makes the following assumptions about components:
First assumption is: “Components are a <div> with something inside”. This implies components are rectangular blocks.
As example a simple list:
<ul>
<li>…
<li>…
<li>…
</ul>
This will not work. But the solution is simple, as you just need to wrap it with an <div> during authoring mode. The slightly/htl-markup is pretty simple.
<div data-sly-unwrap=”${wcmmode='disabled'}>
<ul>
<li>…
<li>…
<li>…
</ul>
</div>
A problem might occur, if the CSS styles doesn’t work with the additional div. Then the AEM developers have to add authoring-specific CSS – which is better to avoid. With the classic UI the problem was even worse, as AEM/CQ added a lot of DIVs inside the html (just for authoring).
Next problem comes, if the list items are more complex – and are components by themselves. Then just for authoring it should be DIVs in DIVs.
Rich Text:
Another common issue with non-AEM designers is formatted text. AEM comes with a powerful richtext editor. Here the solution is, that the designer takes a look into the richtext editor, its features and the created html. Normally the designer just changes the html and css to get along with the richtext editor as it is shipped with AEM.
Tables:
Different story are tables. AEM comes with a powerful table editor as well. But the html is often not sufficient. Often the table editor is taken, but for rendering the html of the table editor is parsed (as example with JSOUP), and then transformed to fit your needs (inside an Sling Model class).
Layout:
In AEM you can stack components inside components to create a complex layout. The outermost component is a page – which is a rectangle by default.
Inside components you have the following options:
- Just the content of the component
- A fixed layout of content and sub-components. A sub-component is rectangle again. And a subcomponent might be just a wrapper, where a human user (author) can drop any arbitrary other component (any means: its configurable which one)
- A parsys, which an out-of-the-box component for a paragraph system. Its a top-down flow of components with the same width. To some extend even with different widths. Also here the human author can add, remove and re-order any components that he/she wants. (and it can be limited by configuration)
- Some column-support – but often not used
- Anything you want - but the editing functionality is then NOT out-of-the-box.
Parsys: This is a very powerful component, and AEM developers tend to take it for everything. So parsys should be your best friend. As example you have a carousel component. The carousel slides are components itself. So in authoring-mode the carousel works as is – and just has a “start editing” button. Then the carousel converts in a parsys of carousel slides. In the parsys you can add slides, edit, remove and reorder them. Finally the user can click the “finish editing” button – and the parsys converts to a carousel again.
BUT all of the above is pretty standard AEM business. In every project are some components that don’t easily fit – and the AEM developers have to find a way for authoring.
As summary for a designer, these rules occur:
- Publish Mode -> Anything goes
- Authoring Mode -> Only rectangular block elements
- Parsys is your best friend. Use it, even if it doesn’t look like a parsys in first place.
Hopefully this helped a little. Maybe your AEM developers are just familiar with bootstrap and prefer it.
