I have a simple requirement of creating a schema for resources. One way to do is add fields for multivalue key value pair and we can add as many as key value pairs in the component. But only thing which we need to keep in mind is that we want to restrict content authors to not to change any "key" in this component. The other approach is to add as many as "text" fields in the schema for different resources for example: text field with description "Please enter text for find" etc. In this case content author has to just put the text which he wants to enter. This way author wont be able to touch the "key", only has to provide "value". Which approach should I follow. Is it ok to put many fields in schema? is there any way to restrict user to not to change anything in "key" field?

  • How many fields are you talking here? Consider that the more fields in a schema you have, the heavier will be the load on your browser (and client's memory usage). A few hundred will be ok; whereas a few thousand will probably be too much. Commented May 13, 2014 at 7:39
  • we may be having around 100 (max -200) resources to be added. SO we can add it in schema itself. right?
    – user918
    Commented May 13, 2014 at 8:56
  • Clear descriptions, examples of appropriate text, and good defaults will all help with content forms of 100-200 fields. The answers pointed out the biggest concern with a key-value approach is BluePrinting. Bascially you can accidentally "lose" an important key and new keys won't be added in localized components (possibly painful in large BluePrints). My best advice is to test your approach with an actual author or two. The preference I've seen is authors want to edit related things in context, with other related things. Are all your fields related? Commented May 13, 2014 at 16:57

3 Answers 3


There isn't really anything wrong with a Schema with lots of fields, other than the fact that editing the Component based on it will not be a pleasant task. Loading will be slower with a large number of fields, but if you need to scroll several page lengths to get to the field you want to edit, well you can see that UX wise this is not preferred.

As the others mentioned, you have the option there to separate it into multiple Schemas, so that everything remains manageable.

If you expect the number of fields to change in the future, then I would opt for an embedded Schema with a Key and Value field. To prevent the normal editors from changing the keys, you can use a UI extension to lock down the key fields for certain groups of users. An example of that is given in the Field Behavior Injection project.

  • 1
    When there is a massive amount of fields, you can use Control-F (search on page) to find and go directly to the desired field without painful scrolling. Commented May 14, 2014 at 5:39
  • @NickoliRoussakov that is a good tip indeed, but as an editor I would still prefer a less fields and multiple Components I guess. Commented May 14, 2014 at 7:28

The is an excellent discussion surrounding this subject on John Winter's Creating translatable website labels in SDL Tridion post over on Tridion Developer.

There are lots of interesting opinions surrounding the pros & cons of using key/value pairs against having set fields within a Schema, and Alvin also mentions an idea the he submitted to the Tridion Ideas site.

In addition to this discussion, you may want to consider splitting your resources out in to multiple Components (and updating the templating code to reference these), rather than having lots of Fields. That way, you can group related labels/resources together (e.g. Form labels, search labels, etc.) and you will also be able to control the security on these Components separately, if needed.

  • Thanks Jona, this approach is what I mentioned in my question also. I just wanted to confirm it.
    – user918
    Commented May 13, 2014 at 9:18

For one implementation I created separate fields for each label so that the key (field name) could not be changed across the BluePrint. On other implementations this was not important so an embeddable schema with key-value fields was used. There is no right or wrong here. It depends on your CMS users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.