In Part I, we spoke of difficulties that arise when you deal with complex legacy AEM components that continue to grow. Such components need refactoring before they get overwhelmed by their numerous features, bugs and fixes. This may, however, feel like pain itself, especially as it comes to matters of changing or retaining component design and user experience. Luckily we have the AEM Authoring Toolkit and its DependsOn feature that help to reorganize legacy code in an unobtrusive manner. We’ve shown some techniques; you can find many more in our previous articles or in the manual on GitHub.
In Part I, we managed to refactor the complicated Swiss Army Knife component and its authoring dialog so that it does not look messy anymore, all of its facilities distributed between tabs. There’s still room for improvement, though. We have many tabs now, and a user can still get lost among them. The settings are better organized but still live in more or less the same “box.” The verification and processing routines attached to them can easily entangle things all over again. It’s much like headphone wires in your pocket; right now they are alright. Then you stick keys or a coin in there, too and… here we go again.
The question of thorough decomposition is: whenever we have a component that can operate differently depending on settings, wouldn’t it be more natural if a user selected the “operating mode” first and then dealt only with settings for this particular mode?
When we use our Swiss Army Knife, we can convert checkboxes like this tool can cut, can saw, or can open into a single selection that answers the question — what do we want this particular instance to do? Then we can show the “details” tab referring to the selected mode and hide the rest of the tabs. The Toolkit’s @DependsOnTab is intended for this exact process.