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. 

cmssupport11 DCT
  • in reply to Mark Saunders

    By linking - something I recall using in the past is to have a group of components that are linked into a container that's finally linked into a page. In the case I recall we had a natural grouping using the title so we had container components
    a-g
    h-m
    n-s
    etc.

    then these container components can be added as individual presentations on the page or within another single container to reduce the CPs (weigh up the benefits of depth over qty of CPs).

  • 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.

  • In line with the above comments - if the user isn’t frequently updating these RTF snippets wouldn’t something like component linking work better - ever better still just have the components individually created abs stores in a specific folder and retrieve as DCPs or Templatess Conponents. 

  • I agree with Neil, it must be a horrible user experience for the editors having to deal with so many fields at once. 
    I had a similar problem about 20 years ago during a content migration to Tridion with 150 fields. The issue then was that the browser had to render the RTF editor gui for a large number of rich text fields and would sometimes fail when the browser ran out of memory. We redesigned the implementation to simplify editor experience by breaking the design down to use several different content types rather than having one complicated "catch all" content type inherited from the legacy solution. This made it much easier for editors to manage and update the content.

  • Whilst there maybe some benefit in improving RTF loading, having 400 of these seems a bad editorial experience. Wouldn't it be better to limit the amount that can be added and create more than one component?