Quoting Chris Johnson <cxjohnson@gmail.com>:
On 6/4/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
I have been reading the posts and wondering what is so different about a comment. A comment is nothing more than content very much similar to a node.
Well, not quite. There is one very distinct difference that makes a comment very different from nodes as we treat them today. And it's also the one thing that makes it hard to clearly call a comment a first-class object, in a modeling sense.
That difference is:
* nodes are "new" objects. They "start" or "instantiate" a piece of content. They are independent, typically.
* comments are "follow on" objects. They are a "reaction" to a piece of content. They are *always* dependent upon the node to which they refer.
So much for the model. In a practical implementation sense, the questions are different, but need to keep the model in mind.
How is what you describe different from a child node dependent on a parent node? If I have a content type relationship mapping table that maps a parent to a child then the children become the ``follow on'' objects. Further more we can design the content type relationship mapping table such that it maps any content type to another content type. So I can have one content type represent albums and the content be generally about the album and another content type represent songs whose content is about the song and a child of the album. Yes, this is different thinking and I am asking that we think of a comment as nothing more than more content. I am asking that all content be thought of as having possible relationships to each other. IMO, it will make for a more robust API and potentially less code. Obviously others think it is more robust because they build replacement modules for the existing core comment module. Earnie