Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Questions about Touch UI DAM Metadata Schema Standard Tags Form Field (AEM 6.5)

Avatar

Level 3

I would like to better understand the intended use for customizing the default metadataschema to add additional out-of-the-box Standard Tags form fields.  I have been doing some testing with it and am confused by the results I see:

  1. I’ve customized the default metadata schema by adding a Standard Tags field to it.  This new field maps to a custom property (for instance:  ./jcr:content/metadata/myTags).  After doing this, the out-of-the-box Tags field no longer works properly:
  • It doesn’t display all the that were previously saved to cq:tags
  • It’s no longer a tag picker field (see 2 screenshots following)

2-cq-tags.png

cq-tags-no-longer-picker.png

2. The out-of-the-box Tag References feature doesn't seem to work for tags saved in custom properties.  For instance, in the screenshots below, I've saved the "Grayscale" tag to the custom property "myTags".  Yet, there is no reference displayed for it in the Tags UI:

tag-saved-in-custom-property.png

0-tag-references.png

3. Upon saving after authoring the "myTags" field above, 1 of the tags I had previously authored in cq:tags is deleted:

deleted-cq-tag.png

4.  Just curious, why is the out-of-the-box Tags field a Text field?  I had expected it to be a tagfield:

text-field.png

So, to summarize my questions:

  • What is the intended use for adding a Standard Tags field to a DAM metadataschema?
  • If I add a Standard Tags field to the form can I map it to a custom property?
  • Is it expected that I could add one (or more) and retain the out-of-the-box field that maps to cq:tags?
  • Why is the out-of-the-box "Tags" field a Text Field?
1 Accepted Solution

Avatar

Correct answer by
Level 10

Hi kvanstone​,

First of all I just want to say: kudos for the question. Lots of details and screenshot, interesting subject: i give it a solid 9/10  

I think you might be onto something here, looks like a bug Can I just ask what version of AEM you're on?

I just tested on a 6.5.1 and I can confirm that the OOTB Tags field is (inexplicably) a Text Field. Furthermore, it does not display multiple tags correctly:

1852761_pastedImage_0.png1852762_pastedImage_1.png

I think it's time for a ticket to DayCare support for a fix 

That being said, I literally just wrote a tutorial on the subject of metadata schema forms here. You can use the inheritance principle of metadata schemas to re-implement the default schema, and substitute the OOTB (Text) Tags field by a Standard or Smart Tags field, mapped to the same JCR node property (cq:tags). Hope that helps!

View solution in original post

2 Replies

Avatar

Correct answer by
Level 10

Hi kvanstone​,

First of all I just want to say: kudos for the question. Lots of details and screenshot, interesting subject: i give it a solid 9/10  

I think you might be onto something here, looks like a bug Can I just ask what version of AEM you're on?

I just tested on a 6.5.1 and I can confirm that the OOTB Tags field is (inexplicably) a Text Field. Furthermore, it does not display multiple tags correctly:

1852761_pastedImage_0.png1852762_pastedImage_1.png

I think it's time for a ticket to DayCare support for a fix 

That being said, I literally just wrote a tutorial on the subject of metadata schema forms here. You can use the inheritance principle of metadata schemas to re-implement the default schema, and substitute the OOTB (Text) Tags field by a Standard or Smart Tags field, mapped to the same JCR node property (cq:tags). Hope that helps!

Avatar

Level 3

Hello theop76211228

Thanks for your feedback and for confirming that you see the same thing!  I have opened a Daycare ticket and will post back here when I have more info from them.

To answer your question, I am also testing with AEM 6.5.1. 

Also, thank you for link to your article, it is nicely written!  I particularly appreciate the info about validating form fields as we have a few use cases where this will come in handy.