Adobe provides a bunch of powerful tools in Touch UI to help you navigate through a list of resources. The most common and also most complex Touch UI Admin Consoles are Sites and Assets. These Touch UI tools typically allow you to navigate through resources, edit and view properties, select one or multiple resources and apply actions on the selected items.
These resources could be located in a folder, and it’s just about listing the children, or the resources could be everywhere in the repository and are collected by using a query.
AEM is very open and flexible so, most likely, you implemented a customisation on top of AEM that makes use of some nodes in the repository to configure data that will be used by the sites or apps you develop in AEM. But how often do we implement proper screens to manage this data?
My initial approach to get a custom Touch UI Admin Console was always to find a similar out-of-the-box console, copying it, and then rewriting it line by line to get my data displayed. Then carefully — line by line — testing that damn JSP a thousand times, and knowing if I change too much at once, the screen would fail to render.
Why is this still all written in JSP, by the way? Why are there hundreds of lines in JSP, while we have great technologies available like HTL, Sling Models and OSGI Services?
Anyway, my goal was to come up with a Touch UI tool that did not use JSPs anymore, but instead makes use of Java code in an OSGI Service (which I can unit test, yay!), HTL and Sling Models.
Removing the JSP part turned out to be not completely possible, but I reduced it to a minimal set of code, just enough to call the OSGI Service. The HTL and Sling Model also worked out, so victory!
Let me explain how I approached this.