Advanced metadata management allows users to create cascading field rules to form contextual relationships between metadata in AEM Assets. The video below demonstrates new dynamic rules for field requirement, visibility, and contextual choices. The video also details the steps needed for an administrator to apply these rules to a custom metadata schema.
Using Cascading Metadata in AEM assets provides critical search and taxonomy support. However, if a user is presented with too many options or not enough context, proper metadata does not get filled out. In AEM assets, administrators are given the ability to apply robust contextual rules to a metadata schema. Let’s take a look at some examples.
Here, we have one field that is required. The license requirements drop-down. And we’re not able to save the metadata without filling this field out. If we choose unlicensed, none of the other fields related are required. What’s interesting is if we choose licensed, copyright owner and usage terms, all become required fields. If we select credit required, only the copyright owner field is required. This is an example of how requirement rules can be created using dependent fields that rely on data from a related field. Let’s take a look at some other examples. If we switch to the IPTC tab, we’re interested in capturing some geolocation information from the image. There’s a country drop-down with several countries listed. If we select United States, we see a state drop-down appear. If we select a state, a city drop-down will appear which lists several cities in the state of California. Let’s change the state to Florida, and now we see a list of cities in the state of Florida. Let’s change the country to Canada. Now the state drop-down has disappeared and we see a province drop-down with the different provinces in Canada. These are some examples of two other contextual metadata rules. The first is the ability to toggle the visibility of a dependent field based on the value of another field which we saw with the country and state drop-down. The second is the ability to filter a list of options based on the value of another field. This is what we saw with the state and city drop-downs. Now let’s see how these rules are created.
From the AEM homepage, let’s navigate to tools, assets, and metadata schemas. We could edit the default metadata schema or we could create a new schema. I’ve already created a new one called custom and we’ll edit it.
This is the metadata schema editor. If we inspect this license requirements drop-down, we can observe a standard drop-down field definition. We have a label and several choices. Under rules, we can see some differences. We’ve made this field a required property. Here, we also see a few different options for requirement based on a new rule as well some options for visibility and choices. If we select the copyright field and inspect the rules you can see that this field is required based on the new rule. If we inspect the new rule that’s applied, we see that this is dependent on the license requirement of field and that this field will be required when the value of license is checked. Let’s take a look at another field. If we look at the usage terms field, we see that this also has a rule-based requirement. And it’s also based on the license requirements drop-down with the value of licensed. You’ll notice that you can only select dependent fields that are populated as a drop-down. Anytime you’re doing customer requirement rules you’re going to want to do it against another drop-down field. Let’s take a look at some dynamic hide and show functionality. On the IPTC tab, there is a country drop-down that has a list of country choices. There is also a state drop-down that has a list of US states and cities. What we want to do is hide that state drop-down and only show it when the United States is picked from the country drop-down. If we look at this visibility rule, we can see that it’s dependent on the country drop-down and that when United States is the selected value then the state drop-down will appear.
There is also a province drop-down and we want to make it appear when Canada is selected. You can continue to change these visibility rules for additional form fields, so that just one or two dropdowns can really change the metadata schema.
Let’s look at another example. We have a city drop-down that just contains a list of some large cities in the United States. What we want to do is automatically filter that list of cities based on the state that the user has selected. Here we have a choices rule, and we can see that a new rule has been applied and that the dependent is on the state drop-down. On the left-hand side, we see values from the state drop-down and how they map to the choices for the city drop-down. For California, we only want to display cities that are in California. For Florida, we’re only going to display cities that are in Florida. The last thing that we’re going to do after editing our schema is to save any changes and then apply the metadata schema to a folder in the dam. We’ll just select our custom schema and click apply to folder.
We’ve looked at some simple ways to apply dynamic requirements visibility, and contextual choices to access metadata. The best part is that this is all done via the UI. So, there’s no extra coding required that might need to be maintained between versions. With very little training, a power user or administrator would be able to make these changes. -
There are three dynamic rule sets that can be enabled for a given metadata field:
Requirement : a field can dynamically be marked as required to be based on the value of another dropdown field.
Visibility : fields can always be visible or only visible based on the value of another dropdown field.
Choices : (only applicable to dropdown fields) filter the choices shown to the user based on the currently selected value of another dropdown field.