This project is read-only.

Content Types/Content Parts adding fields: recommendation and best practices

Topics: Customizing Orchard, General
Mar 1, 2012 at 1:44 PM
Edited Mar 1, 2012 at 3:13 PM


I would like to know what is the recommendation when creating custom Content Type and Content Parts and adding fields to them.

For instance: if I look at the Blog Post Content Type, I can see it contains a Blog Post Content Part. Which in that case allows to add the custom fields either to the Content Part which would be included in the Content Type, or directly to the Content Type. Same example goes for, Blog, Comment, etc..

My questions:

  1. when creating a new Custom Content Type, should we create a matching Content Part (same name) that would be added to the Content Type (best practices point of view)?
  2. And if so, when adding new fields, should we add those fields to the Content Part or the Content Type? The end result is the same, but is there a difference? (i.e: re-usability, performance, etc..)

In the Book Review custom content type example (Creating Lists documentation), all the fields were added directly to the "Book Review" content type (no Content Part was created). Is this the recommendation?

Thanks for your time responding to my query.

Mar 1, 2012 at 2:35 PM

Fields are always added to a content part, they can't be attached to a content type directly. The admin UI actually makes a content part with the same name as the part in the background when you're attaching fields (at least that's what I've read somewhere, haven't played it yet though).

When I need to have fields I create a new part like BlogPostFieldsPart and attach the fields to that (this is done from Migrations, but I think you can follow the same practice if you like from the UI).

Mar 1, 2012 at 3:11 PM
Edited Mar 1, 2012 at 3:12 PM

Thanks Piedone for your response. You've provided some insights. I haven't played with the code yet, so I don't know what goes on in the background.

My question was specific to the Admin UI, sorry I forgot to mention that. And in fact, the Admin UI, allows to add fields to the Content Part or the Content Type and the end result is the same and transparent to the Content Item.

Once I dig deeper into the source code, I will know for sure how the framework behaves in this situation. However, I would like to know what is the best practice in this case as I'm building a web site at the moment and I would hate to go back and modify all my Custom Types for performance or other reasons.

Mar 1, 2012 at 5:04 PM

1. Depends on what you are doing. There doesn't always need to be a 1:1 between parts and types. I like to package functionality inside a content part so that it can be reused in multiple places. For example I made a slide show content part, which doesn't have it's own corresponding content type. I've since then, created multiple content types that have the SlideShowPart. In many cases though, I do create matching part/type pairs to take advantage of other parts that are already available, such as AutoroutePart, identityPart, CommonPart, BodyPart, etc. My custom stuff goes into my MyPart, which is housed by MyType, and MyType houses the other parts that add features. 

2. Piedone is right, if you attach fields to a type Orchard will create a part with the same name as the Content type and attach the fields to that part. You may as well just attach your fields to ContentParts right off the bat, since that will happen anyways. This way at least you are aware of where the field is being placed. 

Mar 2, 2012 at 2:34 AM

Monarch, Thank you, that's what I wanted to know.

As for your second Point and confirming what Piedone has already said, the only issue I'm facing when adding custom fields to the Content Part, is that Content Part doesn't allow for the configuration of the Fields properties, only when adding fields to the Content Type we are able to do that.

Mar 2, 2012 at 4:38 AM

Is that if you attach the field via the UI? I haven't tried that. I think you do get the ability to define the settings if you attach the field to a part from Migrations.cs.

                , b => b
                    .WithField("CatPicture", cfg => cfg.OfType("MediaPickerField").WithDisplayName("Hilarious Cat Photo").WithSetting(...))

Mar 2, 2012 at 5:54 AM
Edited Mar 2, 2012 at 7:13 AM

Yeah, I meant in the UI.

But, even if you do that in the code as you described, it will be created in the database, in table: "Settings_ContentPartFieldDefinitionRecord"

I tried to go and directly edit the Field Part in the "Settings_ContentPartFieldDefinitionRecord":

<settings DisplayName="Price"
NumericFieldSettings.Maximum="" />

However, it had no effect in the UI. Therefore, I think the settings only work if the field is attached to a Content Type.


Mar 2, 2012 at 8:18 AM

It depends on if you want your content type to be reused across sites or not. If not, go with the UI editing and don't care about how the fields are stored. The UI (reasonably) doesn't tell you about the underlying mechanism that a part is used transparently for fields but that won't hurt you.

If you want to reuse that content type in other sites, create a module and setup the type in its migrations: so do just what TheMonarch has written.

Mar 2, 2012 at 12:45 PM

True,  I'm convinced now this is the way to go.
Thank you guys so much for your help.