Extend Reference functionality

[DiegoFaFe]

Motivation

Using the sdk I've noticed some code that we end up repeating pretty often around References, like having to create a new reference to request a language variant of a content item that I already have, or checking agaisnt Guid.Empty when I want to filter if the items are in the default language/workflow...

Proposed solution

• Add a static Default method to Reference class (will return a Reference instance with Guid.Empty id and default codename)
• Implement IEquatable to Reference class
• Add Implicit conversor from sdk models (ContentItemModel, LanguageVariantModel...) to Reference

Additional context

[DiegoFaFe]

@pokornyd I can prepare a PR with any of the 3 proposed changes if they are approved. Just let me know which ones you see value in

[pokornyd]

hello Diego, pardon the late reply. I'll check with wider team which of your proposed solutions is preferred and get back to you soon, thanks for your patience.

[pokornyd]

I'd say the best approach is indeed to have a static method to create a default reference, e.g.:

    /// <summary>
    /// Creates the reference by empty guid (for entities with default ID).
    /// </summary>
    public static Reference ByDefaultId() => new() { Id = Guid.Empty };

I'm not sure a similar implementation for default codename is necessary. IDs are immutable, whereas codenames can be modified. all default entities come with an empty ID if I'm not mistaken, so I think above method should be sufficient.

do you have a use case for default codename as well?

[pokornyd]

getting back to this as v9 beta of the SDK shipped reference improvements that resolve this.

1. most DTOs and references have been turned into records, thus implicitly handling IEquatable (records come with value equality). references can only be instantiated via factory methods (ById, ByCodename...)
2. helpers ByDefaultId and ByDefaultCodename have been added, resulting in a reference with empty guid as id and default string as codename, respectively
3. decided for explicit ToReference() extensions rather than implicit conversions, due to potential problems in scenarios where multiple environments are managed that don't have matching element/object IDs (e.g. due to being cloned by data-ops, rather than in-app)

I'll close this issue once the SDK is out of beta. note that 1 and 2 are already available in currently released 9.0.0-beta-2 but ToReference extensions will only be shipped with upcoming release

[DiegoFaFe]

I never got a notification for your aug 28th post but just got one for yesterdays... I should have checked on my own anyways 🤦

I haven’t worked on the CMS in over a year, but it seems like every ask is being tackled on that beta, that's great news :)