1

We are using dictionaries in our project for adding static values from the code.

For example :

string path="sitecore/content/home/ContactUs"

instead of path using dictionary and passing dictionary value to path

string path=Sitecore.Globalization.Translate.Text("path")

We have path in static value. We have two option here :

  1. Add value in constant .cs file and get that value from here.
  2. Use Sitecore dictionary.

We are adding values in dictionaries so if we need to change there we can easily change from Content Editor without updating the code.

Can we use dictionary in this way in Sitecore?

Could someone suggest what is the correct way for adding static value in Sitecore if we change it after some time ?

2
  • In my opinion, we should not use the dictionary for path type of information, you should use any link type field for this. Dictionary is typically used for labels that are fixed and should not have any typical logic which can break anything on a website. – Mahendra Shekhawat May 17 at 16:02
  • What do we need to use for above scenario as we can change value in future without touching code ? – User7864 May 17 at 16:05
2

You shouldn't use Dictionary entries for this type of content. Dictionary phrase is versioned field which means you need to copy these values for every single language, and when it is changed you need to change it everywhere (applies when you don't have language fallback in place).

You have four options:

  1. Having these values hard coded in code in some static .cs files as constants - IMHO not recommended option as changing means code change and deployment
  2. Having these link value in config files as elements so they are easily changeable via config entries - be honest - how often these paths will be changed? - good option as it doesn't involve big overhead and no deployment is needed, however content editors and devops need to be aligned when the new content is published so at the same time also configs are changed -> this option however means restart of web app when config is changed
  3. Having template with broad list of Link field type fields on Site level where content editors need to specify new path to that particular functionality -> Good option but needs involvement from content editors and it has additional step for them. Also publishing is needed.
  4. Looking up pages based on template type. You will use SOLR to find pages based on specific template. The most content editor friendly (no additional work for them) and no devops involvement -> IMHO best option.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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