ContentComponent

Content components represent the domain or business concepts in an application. They are the information that is managed and used to drive applications.

Content components should be independent of any particuler application, application platform, or user interface. Specific application logic and user interface is provided in separate components.

In the extreme, for example, it should be possible to publish a component with Zope that depends in no way on Zope, or on the web. We achieve this not through "do what I mean" (DWIM), but by explicitly creating components that provide this functionality.

Terminology note:

In MVC, these are called "models".
In J2EE, these are called "entity beans".

gvanrossum (Dec 9, 2001 4:35 pm; Comment #1) --

I would have expected that a ContentComponent provides content: e.g. a chapter of a book, or a picture, or a wiki page, and that a wiki with three pages would contain three different ContentComponents -- one for each page. Am I totally off base?

faassen (Dec 9, 2001 7:45 pm; Comment #2)

I think you're right, though content is broader than just text or pictures. Other examples of content components might be cars in a used car site, or contact information (such as used in Jim's tutorial).

Content components know about the content and they provide methods to access and manipulate the content in a way that is natural to this content. They could be used in a variety of applications. They also don't provide any user interface.

I think that is what is meant by application-independent behavior. Saying that the behavior is application independent is confusing though; the behavior implemented may in fact be central to the application! It's just aren't supposed to implement any user interface type stuff.

jshell (Jan 30, 2002 11:46 am; Comment #3)

So what we're ultimately talking about here is the equivilent of fine grained business components? I'll try not to raise another jargon war, but when designing a business oriented system where the common objects range from Parties (people, organizations) to Inventories to Warehouses, Content isn't all that natural of a fit. But, it's one I can adapt to easily (more so then names like "entity beans" and "data skins").

jim (Jan 30, 2002 12:39 pm; Comment #4)

You are all right, except that content can have sub-content. In Guido's example, the wiki pages are content, but so is the Wiki. Folder are content, as are their contents, so not all content is fine grained.