Under Community Review

Indeed some architectural improvement might be taken in this area

Would like to know how many customers are using so many RTF fields in one Component

Please vote if you are

A multi-value component that contains 400-500 items that contain RTF take longer to load, save

We have a component schema that has an embedded schema that's multivalue. Within the embedded schema the field is RTF enabled (only the term field). When the number increases to 400 the component takes long time to load and save and browser also crashes.

This enhancement request is for improvements around RTF field loading. 

Screenshot of Tridion Sites Ideas component content with multiple terms including '21st Century Act', 'American Express', and 'Americans with Disabilities Act' with creation and effective dates.

cmssupport11 DCT
Parents

  • I agree this many fields would be a "bad" editorial experience for most regular content. However, this matches the setup I've seen and recommended for configuration or label components. For that use case, a power user or chief editor would want to have all (or at least related) translatable labels, brand names, and other terms centralized into fewer Components.

    Often, this might be a "key-value" type of Component (see an example on TridionDeveloper). But having formatted rich text makes sense when you also need to manage markup like superscript, for example.

    You could then review, update, translate, or even Content Port a single Component on fewer screens than across multiple Components.

    Anyways, there are other content models that could balance editorial experience and performance. Perhaps keywords with metadata, separate components as Neil suggests (though personally, I'd prefer Components in a folder rather than having to link them), a Page with Components might make sense. Some of these models would work better in Experience Space, though. ;-) #justsaying

    The broader user story is as an editor, I'd want to be able to easily manage and translate hundreds of important "terms" in my content management system (in a few screens) to be able to control access, localization, governance, and any automation based on these terms.

Comment

  • I agree this many fields would be a "bad" editorial experience for most regular content. However, this matches the setup I've seen and recommended for configuration or label components. For that use case, a power user or chief editor would want to have all (or at least related) translatable labels, brand names, and other terms centralized into fewer Components.

    Often, this might be a "key-value" type of Component (see an example on TridionDeveloper). But having formatted rich text makes sense when you also need to manage markup like superscript, for example.

    You could then review, update, translate, or even Content Port a single Component on fewer screens than across multiple Components.

    Anyways, there are other content models that could balance editorial experience and performance. Perhaps keywords with metadata, separate components as Neil suggests (though personally, I'd prefer Components in a folder rather than having to link them), a Page with Components might make sense. Some of these models would work better in Experience Space, though. ;-) #justsaying

    The broader user story is as an editor, I'd want to be able to easily manage and translate hundreds of important "terms" in my content management system (in a few screens) to be able to control access, localization, governance, and any automation based on these terms.

Children
No Data