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

Make custom type providers return content type codenames by CLR types #61

Closed
petrsvihlik opened this Issue Feb 2, 2018 · 2 comments

Comments

3 participants
@petrsvihlik
Member

petrsvihlik commented Feb 2, 2018

Motivation

Currently, the generated custom type providers may only get Type by string. It should work also the other way around. This should help us reimplement Kentico/delivery-sdk-net#79 . Here, we've implemented a ContentTypeExtractor that allows the developer to entirely omit the EqualsFilter in the following case:

var response = await DeliveryClient.GetItemsAsync<Article>(
    new EqualsFilter("system.type", "article"),
);

Howto

The TypeProviderCodeGenerator should not only generate the GetType method but also a new GetCodename one. We should generate a dictionary of <Type, string> that would be used by the GetCodename method.

Tip: Create a NuGet package of https://github.com/Kentico/delivery-sdk-net locally, so that it contains the latest changes of the ICodeFirstTypeProvider interface.

Deployment

Release together with https://github.com/Kentico/delivery-sdk-net/milestone/8

  • release notes of both packages should contain a note about the compatibility
@JanLenoch

This comment has been minimized.

Contributor

JanLenoch commented Feb 7, 2018

@JanLenoch JanLenoch added the blocked label Feb 7, 2018

@JanLenoch JanLenoch changed the title from Enhance generation of custom type providers with both side mapping to Make custom type providers return codenames of CLR types Aug 10, 2018

@JanLenoch JanLenoch changed the title from Make custom type providers return codenames of CLR types to Make custom type providers return content type codenames by CLR types Aug 10, 2018

@JanLenoch JanLenoch added this to Priority in Prioritization Sep 4, 2018

@petrsvihlik petrsvihlik removed the blocked label Sep 4, 2018

@matus12 matus12 self-assigned this Sep 7, 2018

@petrsvihlik

This comment has been minimized.

Member

petrsvihlik commented Sep 13, 2018

fixed in #75

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment