AEM part1

Our articles on AEM Authoring Toolkit have attracted some attention and brought numerous questions. Thank you for your interest, and please do not hesitate to keep asking us questions!

We’ve noticed that most of the questions are quite specific. Several refer to the multifield component in AEM Touch UI — the tool to propagate entries that have the same logical structure. When you need to store not just one value but an array (which may actually contain no value at all), you are definitely looking for a multifield. You should also use a multifield if you want to store “records” that cover several values. You can think of it as kind of a tiny spreadsheet or a database within a dialog.

For historical reasons, facilitating a multifield in AEM is a pretty complex task. Before version 6, and even after — as long as the Classic UI thrived — AEM multifield was a partly provided, partly hand-made feature. At the very least, it needed a decent front-end input to become useful. Things changed for the better with the advent of Touch UI. Now multifields are fully functional but still require a little bit of a tune up.

At Exadel, we found a way to set up AEM Touch UI multifields in a snap, and of course we’ve brought this feature to the Toolkit.

It’s not uncommon to edit a dictionary-like structure in a dialog. Think of a set of child resources for a component, each defined by a path and a special flag, like “show to the left” or “to the right.” You can also imagine a list of links that will be rendered to the user. Each one has some text, a reference value, an associated icon, etc.

A multifield for a case like this is called a complex multifield. We need a field in a Java class that will declare it and then a secondary Java class that will define a single multifield entry:

As the dialog is saved, this kind of multifield creates a tree-like storage structure: a node with the name of the underlying field variable (entries in our sample) and its children, each representing a single entry. Values of fields defined within the “entry” class will become attributes of the child nodes.

The “entry” class may be a nested private one or a public class in its own right. Therefore, it can be reused across different components in AEM Touch UI or even pose yet another dialog in some other context — it would still serve as a multifield entry.


An even more common situation is one in which you need to store any number of same-typed values: paths, addresses, phone numbers, etc. This is called a simple multifield. It does not create any trees within the component storage; it just populates array-typed node attributes

Generally speaking, creating a simple multifield in AEM Touch UI dialog is no different; we just switch to an “entry” class with a single field and a single widget annotation.


That’s how it would look. Please pay attention to the fact that if we use an “entry” class with a single field we do not need to specify a label for that field. Only a label defined beside @Multifield annotation will be rendered.

If you think the “nested class for a single field” usage looks like overkill, you’re right! It inflates the amount of boilerplate code, to say the least. So in Toolkit v. 1.2.1, we managed to bring the boilerplate-related hassle in the most basic case down to just one line of code.


You now have a good old @TextField, or @PathField, @DatePicker… or anything else. Then you add @Multiple beside it and voila! The properties and behavior of the TextField widget are propagated to multifield entries or planted at the “whole” multifield level, depending on where they are truly bound. You don’t need to worry about anything else.

We hope you haven’t forgotten the MultiFieldEntry fieldset where we started. What if we added @Multiple directly to that one?


See — it works! It has even picked up the input from our previous exercise. While there’s not a great deal of difference between using @MultField and @Multiple @FieldSet, you may still find that it’s well worth it for you. With the AEM Authoring Toolkit, you can even arrange a multifield of AEM TouchUI multifields without breaking a sweat.


This would be most useful when you have to handle really complex data structures.

Today we’ve seen that the multifield components in AEM Touch UI are a useful feature, and that with the help of AEM Authoring Toolkit, turning them on is a straightforward task. You’ll find even more examples and explanations in the Toolkit’s repository on GitHub. See you next time!

Author: Stepan Miakchilo

How can we help you?
Contact Us