Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
BedrockMission!

Learn More

View all

Sign in to view all badges

Refactoring Complex AEM Components and Pursuing Better Code Practices with AEM Authoring Toolkit, Part II | AEM Community Blog Seeding

Avatar

Avatar
Establish
Community Manager
kautuk_sahni
Community Manager

Likes

1,130 likes

Total Posts

6,151 posts

Correct Reply

1,144 solutions
Top badges earned
Establish
Coach
Originator
Contributor 2
Contributor
View profile

Avatar
Establish
Community Manager
kautuk_sahni
Community Manager

Likes

1,130 likes

Total Posts

6,151 posts

Correct Reply

1,144 solutions
Top badges earned
Establish
Coach
Originator
Contributor 2
Contributor
View profile
kautuk_sahni
Community Manager

21-01-2021

BlogImage.jpg

Refactoring Complex AEM Components and Pursuing Better Code Practices with AEM Authoring Toolkit, Pa... by Exadel

Abstract

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.

Read Full Blog

Refactoring Complex AEM Components and Pursuing Better Code Practices with AEM Authoring Toolkit, Pa...

Q&A

Please use this thread to ask the related questions.

AEM AEMEBlogSeeding Experience Manager