Exadel Authoring Kit for Adobe Experience Manager Version 2 Makes AEM Authoring Easier

Meet Exadel Authoring Kit Version 2!

Winter is over, and so is the wait for the new release of Exadel’s authoring solution for Adobe Experience Manager. It’s time for Exadel Authoring Kit for AEM Version Two, and numerous shiny new features are coming with it.

But wait…was there even a version one? Yes, we’ve rebranded the AEM Authoring Toolkit for a new release.

The AEM Authoring Toolkit was one of our flagship projects for the AEM ecosystem, and the Authoring Kit will remain one, too. But now it’s also a proud member of the Exadel Toolbox family – and, in some respects, an ambassador of the Toolbox for our long-term customers and supporters. We even continue to call it ToolKit informally.

As a part of Exadel Toolbox, the Authoring Kit delivers an even better experience for AEM developers, content authors, and business folk. All the Exadel Toolbox solutions work in harmony and are going to be integrated where reasonable to produce seamless development-to-support userspace with AEM component development, package management, and AEM content authoring in the same armory.

New Features that We’re Offering

As for the Exadel Authoring Kit for AEM, it has undergone some refactoring and optimization but fully supports user code written for version one. Still, you should expect to do some redecorating to fit with what we consider AEM content authoring best practices.

First, the project structure. What used to be the aem-authoring-toolkit-api dependency in your project’s POM file is now the etoolbox-authoring-kit-core module. It contains both the API and some brand-new AEM component development tools. The etoolbox-authoring-kit-all package is there to replace the old “assets” package and is responsible for deploying server-side logic (the OSGi bundle and the JavaScript/HTML assets) to an AEM instance.

Second, there is the new recommended API usage. You can still declare an AEM component with a sole @Dialog annotation, but we now offer a more profound approach with @AemComponent for component-wide features and @Dialog manifesting features just for dialogs. There can even be a component without an @Dialog! On the other hand, you can now declare a component that has one, and it also has a Design Dialog with a different composition.

Of course, it’s still possible to set up an AEM component with in-place editing config, child editing config, etc. Uniquely to the Authoring Kit, however, you don’t need to hook all of these annotations on the same Java class. Our solution is capable of “assembling” the component from different classes or interfaces, some of which can be shared across multiple components.

Interfaces? You read that right! Exadel Authoring Kit for AEM now allows you to declare AEM Touch UI dialog fields that are not only Java field-based, but also method-based, and you can explicitly reshuffle them by specifying the order, like @Place(before=…) and @Place(after=…).

Third, there’s the updated layout model. In addition to the well-proven Tabs, it’s now also possible to shape an AEM dialog as an accordion. You can also nest an accordion, or even a set of tabs, within another container to make your layout more detailed. There are more AEM Touch UI dialog widgets supported than in any previous release, with @AnchorButton, @Hyperlink, and @Text on board.

Customizing Authoring Kit in a Snap

The fourth new feature is the completely reworked handlers and customization API that provides native methods for traversing and modifying markup. Functional style and lambdas are included, and there are no more annoying XML manipulations!

Custom handlers have also become a much more intuitive tool for AEM component development. You can hook a handler to any of the built-in annotations and modify any kind of Touch UI markup to your needs, whether it’s a dialog, an in-place editing config, the component’s declaration itself, or anything else, for that matter. You can even write a custom annotation so that its values will be automatically mapped to any of the AEM component’s internal nodes (again, not only the dialog but also in-place config, etc.). You don’t need automapping? Introduce another custom handler or reuse an existing one! Any handler can be triggered by any number of annotations.

The fifth is the OptionProvider mechanism — a way to create a list of options consumable by option selector AEM components, such as @Select/ (Dropdown) or @RadioGroup, from an EToolbox List or an ACS Commons List, a tag folder, or just a node with its child nodes. OptionProvider allows you to modify options on the fly as a foreign component’s value changes. Imagine a path picker and a dropdown placed in the same dialog; as soon as the path to a JCR-stored list is selected in the path picker, values of the list appear in the dropdown.

Extending Authoring Experience

Last, but certainly not least, is our beloved newborn — EToolbox Lists. This is a partly independent solution that is also tightly integrated with AEM component development tasks. The Lists provide the ability to create structured data sets (data sheets or dictionaries). AEM developers know this feature from the well-known ACS AEM Commons solution. The difference is that the ACS Lists are merely key-value pairs, while EToolbox Lists can contain an arbitrary set of values of any type per item. This makes them resemble a tiny built-in spreadsheet solution. Naturally, a list item is designed with the common Authoring Kit API, much like any AEM component.

And this isn’t even a complete list! There are a great deal more optimizations in both Java and DependsOn. We would even venture to say that it’s easier to figure this version out than version one, thanks to new documentation with more code samples that explain AEM content authoring practices and real-world use cases. Check out the project’s GitHub page.

More articles on the new Exadel Authoring Kit for AEM features to come. Stay tuned!

Author: Stepan Miakchilo