hi, welcome everyone. we are glad to have you here today and walk you through user interface customisation opportunities in Adobe Experience Manager 6.
Before we start, let me quickly introduce ourselves.
Damien is… working on our full UI technology stack and technical architect of the new page authoring For my part, I’m leading a small team of developers with focus on the UI framework, WCM administration and page authoring.
As you may know, we did quite a lot of UX changes in the last couple of months for several reasons, one of them being the support for mobile devices. Therefore, we built our new UI to be mobile first, but still keeping desktop in mind by leveraging responsiveness features. It is now spread across multiple UIs of the product, and based on a UI framework that provides the foundation components.
We are going to show 3 major ways of extending the AEM 6.0 UI: Modifying an existing admin screen Creating your own one And finally see how the page authoring interface can be customized
You’re used to have your CQ pages composed of nodes and their appropriate rendering component. Admin UIs are now also built the same way, which easily allows integrating further features and customer extensions. So the structure is similar to what is stored under jcr:content nodes of your CQ pages. Sling resource merger and Includes are two features that help in customizing this node structure.
You had to copy the whole subtree —- CLICK All nodes and properties were duplicated, and you added your customisations there —- CLICK If we did a major change, for instance a new feature —- CLICK, your duplication wouldn’t contain that change. You might also miss some important bug fixes, which you’ll have to re-apply by yourself.
Now the idea is to extend within the apps tree only what’s required, in an almost empty subtree. —- CLICK So when you add a customisation —- CLICK —- and Adobe finally upgrades the console —- CLICK Any intermediate update will be got for free. —- CLICK — This is true for functional fixes, new features or even security fixes which might affect your system. In the end, your customisation is applied on top of the UI Adobe provides.
What I just explained is now possible through a new feature that has been contributed to Sling, called Resource Merger, and is based on a custom resource provider, which is an OSGi service that reads a resource from the JCR repository, and returns it as an object. This object is built by iterating over the resource resolver search paths, and merging those resources together like a diff thanks to a custom Sling vocabulary but also respecting ACLs. Easier debugging for you, the developers.
In order to add or override…
If you want to hide one or more properties…
You might also want to hide a whole subtree of resources. For this, you …
Similar to hiding properties, you can also hide some children by using…
And finally, you can also influence the order of the nodes by using…
I recommend you to check our examples to see how this is applied to the Sites administration. As you can see, we can add a custom toolbar action or restrict the behaviour of another one to some group membership, even change the default layout, and all of this by just providing the corresponding diff under /apps. For you, partners and customers, Sling resource merger will really become your friend.
You might not only want to extend existing admin screens, but also create your own ones to display and edit any kind of custom resources you are storing in the repository. As an example, we might want to create a new console for managing our Launches in the new UI — CLICK —- with its specific actions —- CLICK —- And we’re also going to append this item in the navigation. —- CLICK
So for this, we’ll have a space in the repository for our new console —- CLICK This will contain some specific components with styles, scripts, etc. —- CLICK —- as well as the page definition —- CLICK By using granite UI foundation page like OOTB consoles —- CLICK —- you can build your custom screen using the same mechanisms and in the end getting the exact same user experience
To add the item in the navigation, you extend the default navigation thanks to the Resource Merger —- CLICK —-map it to the right location and its corresponding id for the navigation —- CLICK — and eventually specify where in the navigation tree it should be displayed.
The last item I’d like to talk about is Granite UI include component. If different places of your UIs are requiring the exact same node substree, —- CLICK —- you can store this subtree in a common place to avoid duplication —- CLICK —- and reference it from the include component as shown here. —- CLICK —- It can for instance be used if you want to extend a component dialog. You can reuse parts of the existing dialog in your extension.
TODO: create a custom component with overlaid dialog and add it to samples (no demo)
I will now continue with the third part of our presentation- the page authoring. As may have noticed. the authoring has slightly changed its look and feel :) In 5.6.1 it was already preview technology. To give an understanding of what i m talking about let me walk you through the basics and clarify some expressions.
Part of the EditorFrame is the Sidepanel. The Sidepanel provides multiple tabs on the very top. The first tab we see here is the assets tab. Assets can be added to the page through drag and drop - PAUSE AND CLICK - We can see images on the screen now but the side panel provides to show different groups of assets like videos and documents. The highlighted drop down will be important for one of our extension points.
The second tab of the side panel shows all available components which can be added to the page.
So back to the contentFrame. All the elements highlighted in red are called editables. It is important to understand what’s an Editable.
instance of a component on a page it is a JCR node on the client side there it access to html dom node this object
From the perspective of a developer… - find the definition of the object in the JS namespace Granite….
A little bit more confusion. At the same visual position of the Editables there are also elements called OVERLAYS. While Editables build a connection to an HTML element inside of the ContentFrame, The overlays represent an HTML element in the editorframe. Overlays protect Editables from direct communication. They are invisible and react to user input. Any user interaction like click will happen on the Overlay instead.
So what happens when we click on an Overlay. Usually we get a toolbar. The toolbar defines the action which can be done with the editable.
In some cases if you double click you open an inplace editor. Like the image editor for example.
The glue between all these elements and features are a concept called layer.
New concept to make the page authoring more modular
- State: Which gives you a way to change the way of rendering and functionality. For example you can control what happens when a user clicks on an overlay Or control how an overlay should be rendered Or show a custom sidepanel
Layers are a new concept. independent bundle of functionality which can be activated in order to manipulate or interact with the page The glue. Each of them is loaded separately, completely control experience a lot of power, as long as u r responsible
So lets finally dive into the actual extensibility opportunities. I must warn you, I will show QUITE SOME CODE on the next slides I will explain you 5 of the most important extension points
- client library to add all JS for extension points. loaded in time. namespace contains all objects we are working with, DO NOT use for your stuff oM current loaded page editables page information like path, design, acl, components
The first extension point we will have a look is the toolbar. So after clicking on an overlay we see a toolbar. And we want an additional action on this toolbar.
As you used to do it you can still add your action to a component changing editConfig - this is working as before.
—- Demo 1: create the nodes in /libs/foundation/components/image/cq:editConfig cq:actions=EDITANNOTATECOPYMOVEDELETEINSERT
We can now also add actions to the component with JS This allows us to add actions which are not bound to a specific component, they can be global or restricted to any other property
I will do a DEMO. In this example I build a button which renders the editable into an image. Therefor I am using an open source project called html2canvas. Does not make too much sense, image to image
Our next extension point will be about creating new page actions.
In the screenshot you can see I added a new button on the very top of the page. So when the button is clicked I want to perform an action like starting a workflow.
This can be achieved by leveraging the resource merger which was presented by Gilles beforehand.
So when you look at this very long path on the button. If you add your button there, you will see it in the page authoring.
I won’t show a live demo here but of course we have a code example ready for you to look at.
The next extension point is about the inplace editors. As you remember when you double clicked on certain components then you activate the inplace editor. On the left side we the image editor and on the right side the rich text editor.
To be most flexible, existing inplace editors can be overridden or new ones can added. Therefor we use a submode of the editConfiguration of a component.
We use a node called cq:inplaceEditing and place a property editorType with a unique editor name there.
There is a special case for inplace editors when a component allows to use different editors for different parts. A good example is the Text & Image component. So when clicking (CLICK) on this component. We see a menu showing up which allows us to pick the right editor. We call this kind of editor an hybrid editor because it allows to merge multiple editors
The hybrid editor can be reused to create your own custom editor combinations. Here is some example code I won’t going to explain, just have a look if you want to try it out.
So Authoring extension point number 4. The actual most powerful one. Creating your own layer gives you the power about the whole authoring and plays nicely with other layers. So other bundles of functionality.
inherit or scratch
Here is an example of a custom layer. particular view for MSM websites Let me try to walk you trough the code
NO DEMO but we have a flickr example
Limitation: ExtJS code cannot be converted
so what you learned today…. Leverage the resource merger and includes to extend admin screens, how to create completely new admin screens and how to customise the page authoring
official doc: http://docs.adobe.com/content/docs/en/aem/6-0/develop/extending.html
link to sample packages qrcode
Please give us feedback on this session. We will try to publish as many examples over the following months as possible. If you want to know more about a specific customisation or you are wondering how you can extend a certain area or feature of AEM, please drop us a message. We will do our best to integrate it into one of our public examples/speeches, blogs etc.