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).