Kentico Kontent - Delivery SDK for .NET - Custom Type Provider - Best Practices
•Télécharger en tant que PPTX, PDF•
0 j'aime•12 vues
Strong / weak / static / dynamic typing Advantages of static & strong typing ITypeProvider Creation of Content Item models (flow of the ModelProvider) Tips & tricks Best practices for extending models
Recommandé
Recommandé
Contenu connexe
En vedette
En vedette (20)
Kentico Kontent - Delivery SDK for .NET - Custom Type Provider - Best Practices
- 3. • •
- 6. • • •
- 9. • • var itemsOfVariousTypes = deliveryClient.GetItemsAsync<object>(new InFilter("system.type", "brewer", "coffee")); • • •
- 10. • • • • • • .Cast<Article>(); // If the collection contains only Articles • .OfType<Article>(); // If the collection contains multiple types • • • public partial class Coffee : Product • override decimal? ProductPrice { get => Price; set => Price = value; } •
- 11. • • • • • •
- 12. • •
- 13. •
Notes de l'éditeur
- CustomTypeProvider - Internals
- https://en.hexlet.io/courses/intro_to_programming/lessons/types/theory_unit https://blogs.agilefaqs.com/2011/07/11/dynamic-typing-is-not-weak-typing/ Static: 1. type check during compile time 2. execution Dynamic: 1. execution 2. type check during runtime Weak vs. Strong: how serious we get about type checking (Weak: lots of implicit type conversions, etc.) C# - statically typed (except for dynamic keyword), strongly typed (but offers some meaningful implicit converstions, e.g. Int->float)
- Weakly-typed approach is good only when you need to access raw data. Some of the new features are not supported with the weakly-typed approach.
- Strongly typed views – no need to take the data from ViewBag or @model dynamic (e.g. https://github.com/Kentico/kontent-sample-app-net/blob/master/DancingGoat/Views/Product/Brewer.cshtml) Display Template – standardized way of rendering a type (without knowing what the type is consisting from upfront)
- Recursion: We prevent infinite loops by keeping track of already processed items
- You can use <object>: var response = await client.GetItemsAsync<object>(); and it‘ll still be strongly typed inside Supporting <object> is important because we don‘t know of what type will the linked items be Defining the top-level type GetItemsAsync<Article> is important just for the convenience of the consumer (intellisense, etc.), internally it‘s always typed correctly - This requres the ITypeProvider to be present
- SLN: Need to customize a partial class Query two content types + use runtime typing+ use display templates Abstraction layer via a partial class (or potentially a better delivery api query) Structured rich text + foreach through the collection of RT items and filtering only those of the HostedVideo type