With the onset of AEM 6.x, Adobe introduced a new modern-looking authoring framework known as touch-oriented interface or Touch UI. Its underlying Granite framework delivers excellent options for authoring on any type of device. You can arrange complex editing dialogs however you like, enjoy the same experience on any device and/or breakpoint, and implement most of the logic in the inline editing mode. AEM 6.x has got all the power and dashing good looks of the Coral 3.0 interface.
But there is a tradeoff between the modern interface and usability on the one hand and dev complexity on the other. Dialogs and widgets are defined via JCR node sets, and their structure is not in the least bit simple. Many dialogs, however similar they may be, need just as many defining node sets. Data for dialogs and inline editors serving the same component are sometimes plainly duplicated.
This means that the good old “changed once, missed to change elsewhere” problem is in full force here.
Furthermore, the general consensus is that the component is king, and when it comes to feature implementation requests, the change should be in the Java-coded model, and the authoring interface should only reflect that change. We dream of the day when AEM devs can modify or extend their Java code without being bitten in the behind by the ever-present need to fiddle with XML.
AEM Authoring Toolkit is the open-source set of tools for creating comprehensive TouchUI dialogs for AEM components with use of existing and/or specially designed Java classes. The Toolkit is aimed at providing the fastest and most intuitive way to supplement an AEM component based on a Sling model class or a POJO with a Touch UI dialog and in-place editing interface.
vs Authoring Toolkit
In fact, there's virtually no necessity to edit TouchUI dialogs via XML or crx/de interface anymore.
It works at the package phase of Maven-powered project building process. Dialog markup is autogenerated based on the values of specific Java annotations added to fields of Sling Model / POJO use classes. Then the markup is injected into content package before their deployment to JCR.
Resulting dialogs and editors are compliant with the newest facilities of AEM 6.4+ / Coral UI v.3+ and have support for Coral UI v.2.