This project is read-only.

Add same type of ContentPart multiple times.

Topics: Core
Oct 21, 2012 at 7:00 PM
Edited Oct 21, 2012 at 7:07 PM

It is not possible (at least from UI to add multiple content parts of the same type. For instance, there might be a case when several BodyParts are required for type.

Is there are special reason for it? Technically I see it similar to fields, ContentPart just need a Name property to distinguish between. For backward support .As<ContentPart>() could return the first Part. And .As<ContentPart>(string name) - the named part.

Oct 21, 2012 at 7:12 PM

Ok, The content placement. hmm. Maybe an attribute can be used..

Oct 21, 2012 at 7:24 PM

The special reason for it is that if you need more than one, you probably should be using a field. A content part with a name property that there can be more than one of *IS A FIELD*. The text field is perfectly appropriate for that usage.

Oct 21, 2012 at 7:47 PM

Is that mean that BodyPart should be implemented as Field? ;p

Oct 21, 2012 at 7:52 PM

No, it means that body part is for that main content that many types have (Page, Blog Post, etc.), and that there is also the text field for those types that need several rich text areas. Both exist and have different use cases.

Oct 21, 2012 at 8:01 PM


Just checked -> Body part doesn't consist of fields. IT IS a rich text area with configurable flavor. At the same time, I didn't find the rich text field.

I'm, still not understand why several ContentParts of the same type is a bad idea, I see only technical restriction here.

Oct 21, 2012 at 8:10 PM

Err, who said it was? *Conceptually*, what you are asking for, a part that would be named and that there could be more than one in a type, is a field. See It's not that it's a bad idea, it's that IT ALREADY EXISTS: it's what fields are.

There is no "rich text field", but the text field can be configured to do rich text.

Oct 21, 2012 at 8:27 PM

I see. It is poor that ContentParts are single for ContentType by design. But I can live with it by using combined shapes in the PartDriver.

Just curious about another use case: I'm a user of the orchard, I'm creating a type, so let's call it CompanyPortfolio (can;t imagine better type). I can use multiple rich text fields (hopefullt downloaded from the Gallery),to make ProjectDescription and ProjectTechnologies (or something).

But I also want to make two collections (which is probably a container or taxconomy) - One has Projects (from some other module), Another - Developers (just a set of fields). Is it possible atm?

Oct 21, 2012 at 8:31 PM

On the contrary, it was a conscious decision that I stand 100% behind. I don't think you have provided a good argument that it wasn't.

For those collections, you can probably use a content picker field and configure it for multiple values.

Oct 21, 2012 at 8:43 PM

Right. Content picker might be a good replacement.

Anyway, to finalize, looks like it is possible to "simulate" multiple same content types by "cloning" their parts from the code (ContentDefinitionManager.AlterPartDefinition), as an alternative to Combined Shape.

Thanks for the clarification.

Oct 21, 2012 at 8:57 PM

Not sure what you mean by cloning their parts.

Oct 22, 2012 at 7:48 AM

Sorry, yes, of course "AlterPartDefinition" is not that will make the trick. Then the options are:

1. use fields or

2. use combined parts.

Oct 25, 2012 at 5:04 AM
Edited Oct 25, 2012 at 5:07 AM

Think of a part like of a piece of functionality you add to the item, *not data*. Suppose you have a type called "Duck" to which you've added parts "Animal" and "Quack". There is no need to add them more than once, right? In other words - parts concept is similar to multiple inheritance.

What you really need is to create a 1-N relationship between different items (namely CompanyPortfolio <1> ---- <N> Project). The CompanyPortfolio item would simply aggregate projects, nothing more. The easiest way to achieve that would be to use Container/Containable parts.

Oct 25, 2012 at 10:17 PM

Fields works very well - it would make no sense to add two "Title"-parts to a Content Type, for example.

We are for instance using several Text Fields with display option "Html" to works as additional "Body Parts" in a Content Type. It works very well. I think it's from the "Orchard.Fields" module? The displayment of the extra fields are configurated in the theme to look a bit different than the Body Part.

For the container, we're using different taxonomies added as fields - but I guess content types (as mentioned above) are a smarter solution now.