Reviewing the Content Part definition

Topics: Administration, General
Oct 20, 2012 at 6:25 PM
Edited Oct 20, 2012 at 6:26 PM

Again referring to the root level, now the section on ContentPart:

The definition of the first paragraph is first rate and could be referenced by future documents. It leads into and equally great example - the blog-to-comment relationship. I think it'd be helpful to both devs and builders. And I think it'd be really, really helpful to add other examples right alongside. Like (offered with the proviso that my understanding of ContentParts is only partial - feel free to correct me):

Another example of a ContentPart is the email address. It's easy to think envision an email address as a flat string of characters. When it becomes a ContentPart it can acquire properties like DisplayName, IsValidated, Work|Home|Other. And it can have behaviors like SendForRevalidation, Archieve, Disable and so on.

I think others should be added without harming anyone's attention span.

I read the sentence:

All the parts that form a given content item share the same integer id.

and wonder if it would be accurate to continue with:


Those who are experienced with ORMs would recognize 
this (the int id) as a Foreign Key relationship.



The final paragraph is just out of reach of my ability to parse. Clearly something fundamentally important going on there and might become crystal clear by someone else's interpretation of it:

This of course provides high reusability as the composed units are narrow and loosely-coupled aspects. Still, the size of the aspects is large enough that they can package a whole feature (as opposed to field-level composition that does not enable rich feature sets to be encapsulated as one single entity, and to type-level definition of behavior that doesn't provide easy reuse of cross-concerns that apply to more than one content type).

Oct 20, 2012 at 8:29 PM

Well, yes, you might want to deepen your understanding of parts and fields. In particular, I would not make e-mail a part. A simple test can be to ask yourself if it would make sense to have more than one, named instances in a given type. It is easy to imagine more than on e-mail address on a type: creator e-mail address, contact e-mail address, more info e-mail address, etc. A title on the other hand needs to be a part because a given content item has clearly only one. Same thing for information such as last modification date, owner, tags, comments, etc. No need to name those and have more than one.

Of course in some cases the distinction is more fuzzy and one may go one way or the other. Does this help?

On the id thing I would disagree that it is an ORM concept. It's a relational database concept.

Oct 20, 2012 at 8:56 PM
bertrandleroy wrote:
Of course in some cases the distinction is more fuzzy and one may go one way or the other. Does this help?

Yes it does. But drilling to the idea of an email address that's comprised of a collection of properties and behaviors - a creator's address would have the property value for 'Validated' set to (presumably) 'True' while perhaps not so for a commentor's Validated property. Or would 'Validated' be a  field instead of property?


Oct 20, 2012 at 9:04 PM
Edited Oct 20, 2012 at 9:06 PM

Both a field and a part can be complex entities, so that's not where the distinction is.

Your validated thing should be a property of the field (if it relates to the e-mail address), or a property of a comment, but I'd say they just happen to have the same name but may have different semantics. But it's certainly not a field by itself. If you need a content item to be validated, for example, you could use a Boolean field named "validated" but you wouldn't build a special "validated" field just for that. You may build a Validated part on the other hand. All subtle variations. Is this clear or am I confusing you further?

Oct 21, 2012 at 12:38 PM

Wouldn't say 'confusing me further' I just need to interact with the stuff inside the CMS before revisiting.