No code generation for Content Type Snippets

[ghost]

Just like for usual content types it would be good to have generated classes for content type snippets.

[petrsvihlik]

Hi @djanjicek ,
content snippets can't exist on their own. They are automatically included in the Content type API and therefore in the generated models. Is that sufficient for your scenario?
Or do you see one where you could make use of special content-snippet models?
Please, bare in mind that a content type can contain more than one content snippet so it's should be understood as composition rather than inheritance. (I'm saying that because it's not possible to have multiple inheritance in C#).

[ghost]

Yes, I agree. An interface pattern would suffice.

…

On Tue, Nov 14, 2017 at 10:19 Petr Švihlík ***@***.***> wrote: Hi @djanjicek <https://github.com/djanjicek> , content snippets can't exist on their own. They are automatically included in the Content type API <https://developer.kenticocloud.com/reference#view-a-content-type> and therefore in the generated models. Is that sufficient for your scenario? Or do you see one where you could make use of special content-snippet models? Please, bare in mind that a content type can contain more than one content snippet so it's should be understood as composition rather than inheritance. (I'm saying that because it's not possible to have multiple inheritance in C#). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADdnjFc1St4W00WG_yqgCLSiDc3tk5QOks5s2VslgaJpZM4Qc-Pv> .

[petrsvihlik]

Yeah, interfaces would work fine. Could you please provide a little more context? I'm trying to understand what's the priority of this feature. Is there any real scenario that's not supported / hard to implement at the moment (while we don't have the interfaces)?

Thank you!

[ghost]

The use-case goes about Model / ViewModel mapping. While interfaces play along with OOP practices, they don't cover the support of codename constants. I was too quick about my previous comment. Basically this rules out this option. I can't say:

myViewModel.SomeProperty = ISomeContentTypeSnippet.GetString(ISomeContentTypeSnippet.SomeCodeName);

What I would need would be an interface ISomeContentTypeSnippet plus a concrete implementation of the content type inheriting this interface. Then I could use the implementation for codename retrieval and the interface for ViewModel modeling.

From an OOP perspective is definitely makes sense of using interfaces.

[petrsvihlik]

Can't you do just myViewModel.SomeProperty = ISomeContentTypeSnippet.GetString(ContainingContentTypeModel.SomeCodeName);?

What would GetString() do anyway?

If you had

public class ContainingModel (:ISomeContentTypeSnippet // this would probably go to a partial class))
{
   public string A {get;set}
   public string B {get;set}
   public string C {get;set}
}
interface ISomeContentTypeSnippet
{
   public string C {get;set}
}

why not to access the property by ISomeContentTypeSnippet.C?

[ghost]

Ok, let's start from scratch... There are certain situations where I need to call GetString() or GetModularContent() on an instance of ContentItem. And I don't want to target explicit types.

public interface ISomeModel
{
}

public class SomeModel : ISomeModel
{
    public const string NameFieldName = "NameCodeNameValue";
}

public class SomeViewModel
{
    public string Name { get; set; }
}

public class SomeMapper
{
   public void Map(ISomeModel model, SomeViewModel viewModel)
   {
	viewModel.Name = model.GetString(ISomeModel.NameFieldName); // won't work
   }
}

I'm not sure whether my example explains it entirely, if not, maybe we can have a skype call.

[petrsvihlik]

aaaah.... i see! ContentItem - that was the important missing piece :) now we're getting somewhere! will send you a call invite. thanks!

[petrsvihlik]

So my first question would be - why do you use ContentItem? It's important to understand what's missing from the strongly typed approach that you're forced to use the generic ContentItem.

Because, looking at the example you provided, I could simply object that the following code would work fine:

public class SomeMapper
{
   public void Map(ISomeModel model, SomeViewModel viewModel)
   {
	viewModel.Name = model.Name; // will work
   }
}

[ghost]

Mainly because of ContentItem.GetModularContent(string). I dislike the fact that I would get an IEnumerable<object> otherwise, even if I know the type (e.g. I restricted a single content type). With getting IEnumerable<ContentItem> I can cast to my strongly typed object. I don't think that's going to work with System.Object, right?

[petrsvihlik]

See my comments below

Mainly because of ContentItem.GetModularContent(string). I dislike the fact that I would get an IEnumerable<object> otherwise, even if I know the type

You can find out the type like this new CustomTypeProvider().GetType("article"). See the comment here.

(e.g. I restricted a single content type). With getting IEnumerable<ContentItem> I can cast to my strongly typed object. I don't think that's going to work with System.Object, right?

You can do this: var articles = ModularContentItems.OfType<Article>();. The collection is strongly typed internally. See the comment here. If you want to have a strongly typed collection like this I'd recommend implementing a wrapper property in a partial class like:

public IEnumerable<Article> Articles 
{ 
   get 
   { 
      return ModularContentItems.OfType<Article>(); 
   } 
}

Or do you specifically want to have an IEnumerable of ContentItems? It's true that you can only cast it one way (ContentItem->Strong Type).

[petrsvihlik]

hi @djanjicek do we still need to discuss this or can it be closed? thanks!

[ghost]

Hi Petr, We can close it for now. Best regards, Drazen

…

On Wed, Jan 10, 2018 at 8:06 PM, Petr Švihlík ***@***.***> wrote: hi @djanjicek <https://github.com/djanjicek> do we still need to discuss this or can it be closed? thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#42 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADdnjK2nx5FnlSLcudNv4q8wd7-zPmuRks5tJQoagaJpZM4Qc-Pv> .