Add Support for Generating Management Models using Codename References

[nkooman-bzs]

Motivation

Generated Management models are tightly coupled to an environment since they use ID references. Typically we find that we have multiple environments in our Kontent.ai projects. When creating tools that utilize the Management SDK is becomes difficult to manage n number of models based the number of environments present.

Proposed solution

1. Create a new KontentElementCodenameAttribute in the Management SDK to reference fields using codenames instead of IDs.
2. Update model generation to include a new app setting that controls whether to use KontentElementIdAttribute or KontentElementCodenameAttribute. By default the tool would use KontentElementIdAttribute to prevent breaking changes. Perhaps in a major release we could swap to using KontentElementCodenameAttribute as the default.

Additional context

N/A

[pokornyd]

Hello Nick, thank you for the submission. I certainly think this makes sense and will prioritize it during my upcoming OS maintenance week, thank you for your patience.

[pokornyd]

hello again Nick. this certainly took longer than a maintenance week, but at last, I'm getting back to you regarding this issue.

tl;dr: codenames cannot completely replace IDs for model mapping purposes, because not all management API responses contain codename references, however, element IDs remain identical between cloned environments.

more reading: adding a custom KontentElementCodenameAttribute to the models wouldn't be a problem, but the codename property is actually present on the generated models already, though not as a custom attribute but rather as [JsonProperty("<element_codename>")]. this would be sufficient for mapping purposes, as there are helper methods (GetKontentElementId and GetKontentElementCodename) to retrieve either identifier, which would, in an ideal world, boil down to adjusting GetStronglyTypedElements function to something like this:

var property = properties.FirstOrDefault(x => 
    x.PropertyType?.BaseType == typeof(BaseElement) && 
    (
        (x.GetKontentElementId().ToString() == element.element.id) ||
        (x.GetKontentElementCodename() == element.element.codename)
    ));

regrettably, management API does not provide codename references for elements when you retrieve a language variant, only their IDs. consequently, calls such as await client.GetLanguageVariantAsync<ArticleModel>(identifier); would have to fallback to the ID attribute.

that being said, when you clone an environment, the ID references (at least for elements) remain identical, only the environment ID changes. this of course isn't applicable for environments cloned and restored manually, in which case the IDs regenerate. is this your scenario?

[nkooman-bzs]

Hi @pokornyd,

I completely forgot about this issue, sorry!

Here's my use case:

• I have a project that contains my generated models. (our dev environment models are kept in source control)
• I have a project that builds a CLI tool executable that interacts with MAPI
• I can publish anytime for a dev build of the executable
• Anytime I publish for prod I need to remember to regenerate models for the prod environment.
• We do not often delete dev and clone prod. So over time IDs deviate and it is not maintainable.