-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generate Dictionary Items in a strongly-typed fashion #11
Comments
Hi @hfloyd I haven't really looked into this yet due to lack of time. In your example, When using nested dictionary items, I tend to use the parent alias as a prefix for the child item's alias. Eg. Something like:
People may create dictionary items in lots of different ways, so it might be difficult coming up with something that can handle this. |
Hi @abjerner ! This isn't my example - It's Nik's (@NikRimington) I just copied it over as a courtesy. |
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. |
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. |
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. |
As per @NikRimington from umbraco/Umbraco-CMS#11854 (comment):
The text was updated successfully, but these errors were encountered: