Generate Dictionary Items in a strongly-typed fashion

[hfloyd]

Generate Dictionary Items in a strongly-typed fashion

[abjerner]

Hi @hfloyd

I haven't really looked into this yet due to lack of time.

In your example, TopLevelDictionaryItemWithChildren doesn't really have a value of it's own. Du you have any examples for when it does? The alias of a dictionary item may also contain characters that aren't good for C# member names.

When using nested dictionary items, I tend to use the parent alias as a prefix for the child item's alias. Eg. Something like:

• MyWebsite probably empty
  • MyWebsite.Footer probably empty
    • MyWebsite.Footer.Address ➡️ Address
      • MyWebsite.Footer.Address.Street ➡️ Street
      • MyWebsite.Footer.Address.City ➡️ City

People may create dictionary items in lots of different ways, so it might be difficult coming up with something that can handle this.

[hfloyd]

Hi @abjerner ! This isn't my example - It's Nik's (@NikRimington) I just copied it over as a courtesy.

[hfloyd]

I agree with you that If I have nested Dictionary items, the "folders" are usually blank. Of course, really any dictionary item could return a blank value, since it isn't required via the UI.

In terms of the aliases not being good for C# names... I've used a little string extension (.MakeCodeSafe()) when I've wanted to dynamically generate thinks like HTML ID attributes, etc. So I don't think that would be the biggest challenge to overcome.

[abjerner]

Both my own Skybrud.Essentials (which is already a dependency) and Umbraco also have some logic for creating safe strings. But stripping out unwanted characters could potentially cause conflicts if two different aliases are converted to the same safe string. But if that happens, simple solution could be to return a Models Builder says no style error.

Another issue I hadn't though of before is to actually resolve the dictionary values. If our Models Builder generates one or more static classes with constants (or static readonly fields/properties), we can't really resolve the values in a DI-friendly way, and as a result, the code wouldn't be very testable. That might be bad in some cases, but fine in others.

But if the constants are mapped to the aliases instead of the values, then we shouldn't have problem, but it would require developers to resolve the values on their own.

[hfloyd]

But if the constants are mapped to the aliases instead of the values, then we shouldn't have problem, but it would require developers to resolve the values on their own.

I think that would actually be ideal - so that MB doesn't need to manage the actual Dictionary lookup code - since that is part of CMS.Core and might change.