Recipe vs C# code for creating new Content Types and Parts

[DrewBrasher]

I am planning to create some modules that will need to add some Content Types and maybe Content Parts. I'm not really sure whether I should use a recipe to define them like in the Agency Theme

OrchardCore/src/OrchardCore.Themes/TheAgencyTheme/Recipes/agency.recipe.json

Lines 127 to 139 in 3c0bdb8

	"ContentTypes": [
	{
	"Name": "Page",
	"DisplayName": "Page",
	"Settings": {
	"ContentTypeSettings": {
	"Creatable": true,
	"Draftable": true,
	"Versionable": true,
	"Listable": true,
	"Securable": true
	}
	},

or add them in the C# code like in the Orchard Helpful Extensions https://github.com/Lombiq/Helpful-Extensions/blob/cfd69837ff2e53c5172e1ff3f406a28745fda9d5/Lombiq.HelpfulExtensions/Extensions/ContentTypes/Migrations.cs#L18-L23.

What are some of the things to consider when deciding which way to do it?

[jtkech]

If you have dedicated modules, I recommend C# code by defining dedicated : DataMigration, so that versions are easier to manage by adding UpdateFromN() migration steps, if you want to alter definitions and/or add new table(s), for example index table(s) that would be used by index provider(s), also if you want to alter index table(s) in another migration step ...

[DrewBrasher]

Thank you, that makes sense. Would you also create a strongly typed Part for the Content Type? For example, I need to create a module that provides Helpdesk Ticket/Issue Tracker functionality. So one content type I would add might be called HelpTicket and some fields it would need would be things like assigned user, category, and due date. Would you create a strongly typed HelpTicketPart with those as properties?

[jtkech]

Hmm interesting, yes we do that for some part that we weld on the fly to content types, but only for special purposes.

ATM I would recomment to use the regular migrations using the regular content type/part/field definitions, so many things depend on this pattern ;) But then you will still have strongly typed parts and fields inheriting from ContentPart and ContentField.

[ns8482e]

ContentTypes and ContentPart are defined in content definitions. Use of c# class are just for ease of use. Regardless you use strongly typed or not, you still need to do migration to have those types defined in Content type definitions.

e.g. if you define class Issue content type with name property in c#. You still need to use Create method in DataMigration to add Issue content type definition. Let's say after sometime in next version you are adding Attachment property in your class, you will need to add UpdateFrom method to alter the type definition.

Recipes are also useful to define migrations if you prefer declarative way of defining content types and content parts.

However recipe is not replacement of DataMigration.

As module author, Use DataMigration to provide content type changes between content type definition version. You can also utilize recipe within DataMigration to change content type version from x to y.

[ericrrichards]

Having a strongly-typed ContentPart is helpful if you are doing any kind of manipulation in code on the back-end. E.g.

var fooItem = await contentManager.GetAsync("4dafksd4r251w4fbcxrek3n6mm");
var fooPart = fooItem.As();
if (fooPart != null){
return fooPart.BarField?.Text;
}

Not as useful if you'll only ever be updating or displaying the items with the Orchard UI.