Since it came up, I'll draw everyone's attention to the nodecomment module which makes comments into nodes. Rather, it uses one node type to be the comment type of another node type. To me (and the other Lullabots) this makes a lot of sense. All that is needed is a 1:n mapping between a parent and its children and some special display. What makes the nodecomment module really special, however, is that the rendering of the "comments" is handed off to the views module (which is a requirement), so you could display your comments in totally non-traditional ways, such as in a table or in a calendar. One of the most useful applications that this module has found is also the impetus for its creation: voting widgets in the comments that vote on the parent node. I'm creating a site, for example, where the comments are all ratings of the parent node, and each comment needs to have four separate fivestar widgets. To do this, the comment node type has four CCK fields from the fivestar module where the target of the voting is set as arg(1)... meaning the fields belong to the comment nodes but the votes belong to the parent node. Very cool. We've had clients who have requests like wanting to promote comments to the front page, or rate comments, or categorize comments etc. This module fills those needs. The release says it is beta, and I stick by that, but it is worth noting that this beta code probably serves 5 million page views a day or more on live (rockstar) websites. -Robert http://drupal.org/project/nodecomment
Unfortunately, treating comments as nodes in response to nodes makes the database optimizations particularly difficult for the tracker. It's not impossible to make it run fast, but treating comments as special kinds of nodes takes much elegance out of the design. Robert Douglass wrote:
Since it came up, I'll draw everyone's attention to the nodecomment module which makes comments into nodes. Rather, it uses one node type to be the comment type of another node type. To me (and the other Lullabots) this makes a lot of sense. All that is needed is a 1:n mapping between a parent and its children and some special display. What makes the nodecomment module really special, however, is that the rendering of the "comments" is handed off to the views module (which is a requirement), so you could display your comments in totally non-traditional ways, such as in a table or in a calendar.
One of the most useful applications that this module has found is also the impetus for its creation: voting widgets in the comments that vote on the parent node. I'm creating a site, for example, where the comments are all ratings of the parent node, and each comment needs to have four separate fivestar widgets. To do this, the comment node type has four CCK fields from the fivestar module where the target of the voting is set as arg(1)... meaning the fields belong to the comment nodes but the votes belong to the parent node. Very cool.
We've had clients who have requests like wanting to promote comments to the front page, or rate comments, or categorize comments etc. This module fills those needs.
The release says it is beta, and I stick by that, but it is worth noting that this beta code probably serves 5 million page views a day or more on live (rockstar) websites.
-Robert
Right, but this is a contrib module designed for sites that need that sort of functionality and not headed for do. No? William On 6/4/07, David Strauss <david@fourkitchens.com> wrote:
Unfortunately, treating comments as nodes in response to nodes makes the database optimizations particularly difficult for the tracker. It's not impossible to make it run fast, but treating comments as special kinds of nodes takes much elegance out of the design.
Robert Douglass wrote:
Since it came up, I'll draw everyone's attention to the nodecomment module which makes comments into nodes. Rather, it uses one node type to be the comment type of another node type. To me (and the other Lullabots) this makes a lot of sense. All that is needed is a 1:n mapping between a parent and its children and some special display. What makes the nodecomment module really special, however, is that the rendering of the "comments" is handed off to the views module (which is a requirement), so you could display your comments in totally non-traditional ways, such as in a table or in a calendar.
One of the most useful applications that this module has found is also the impetus for its creation: voting widgets in the comments that vote on the parent node. I'm creating a site, for example, where the comments are all ratings of the parent node, and each comment needs to have four separate fivestar widgets. To do this, the comment node type has four CCK fields from the fivestar module where the target of the voting is set as arg(1)... meaning the fields belong to the comment nodes but the votes belong to the parent node. Very cool.
We've had clients who have requests like wanting to promote comments to the front page, or rate comments, or categorize comments etc. This module fills those needs.
The release says it is beta, and I stick by that, but it is worth noting that this beta code probably serves 5 million page views a day or more on live (rockstar) websites.
-Robert
William Smith wrote:
Right, but this is a contrib module designed for sites that need that sort of functionality and not headed for do. No? Correct. There is currently no serious discussion about making core comments into nodes because this approach has been unequivocally rejected by every core maintainer I've spoken with.
David Strauss wrote:
Unfortunately, treating comments as nodes in response to nodes makes the database optimizations particularly difficult for the tracker. It's not impossible to make it run fast, but treating comments as special kinds of nodes takes much elegance out of the design.
That would be true if they were "just nodes", but since they also directly manipulate the node_comment_statistics table the same way that the comment module does, I think you'll agree that all of your arguments regarding the comment count metric in the tracker query will apply to comments as nodes as well.
Quoting David Strauss <david@fourkitchens.com>:
Unfortunately, treating comments as nodes in response to nodes makes the database optimizations particularly difficult for the tracker. It's not impossible to make it run fast, but treating comments as special kinds of nodes takes much elegance out of the design.
I didn't envision ``treating comments as special kinds of nodes''. Rather I envision treating comments as any other node w.r.t. the content API. Tracking content by content type should be a normal thing to do. One parent node to many child node relationships should be a normal thing to do. Earnie
Thanks for this heads-up. I was just thinking aloud in that other thread, it seems all of that already exists :) Great! Wim On Jun 4, 2007, at 17:56 , Robert Douglass wrote:
Since it came up, I'll draw everyone's attention to the nodecomment module which makes comments into nodes. Rather, it uses one node type to be the comment type of another node type. To me (and the other Lullabots) this makes a lot of sense. All that is needed is a 1:n mapping between a parent and its children and some special display. What makes the nodecomment module really special, however, is that the rendering of the "comments" is handed off to the views module (which is a requirement), so you could display your comments in totally non-traditional ways, such as in a table or in a calendar.
One of the most useful applications that this module has found is also the impetus for its creation: voting widgets in the comments that vote on the parent node. I'm creating a site, for example, where the comments are all ratings of the parent node, and each comment needs to have four separate fivestar widgets. To do this, the comment node type has four CCK fields from the fivestar module where the target of the voting is set as arg(1)... meaning the fields belong to the comment nodes but the votes belong to the parent node. Very cool.
We've had clients who have requests like wanting to promote comments to the front page, or rate comments, or categorize comments etc. This module fills those needs.
The release says it is beta, and I stick by that, but it is worth noting that this beta code probably serves 5 million page views a day or more on live (rockstar) websites.
-Robert
Actually comments as node makes lot of sense specially for community driven sites where comments have equal ( sometime more ) weight when compared to node. If I am not wrong there was some discussion before too that it makes some operation easier like splitting threads, escalating comments , etc. --- Robert Douglass <rob@robshouse.net> wrote:
Since it came up, I'll draw everyone's attention to the nodecomment module which makes comments into nodes. Rather, it uses one node type to be the comment type of another node type. To me (and the other Lullabots) this makes a lot of sense. All that is needed is a 1:n mapping between a parent and its children and some special display. What makes the nodecomment module really special, however, is that the rendering of the "comments" is handed off to the views module (which is a requirement), so you could display your comments in totally non-traditional ways, such as in a table or in a calendar.
One of the most useful applications that this module has found is also the impetus for its creation: voting widgets in the comments that vote on the parent node. I'm creating a site, for example, where the comments are all ratings of the parent node, and each comment needs to have four separate fivestar widgets. To do this, the comment node type has four CCK fields from the fivestar module where the target of the voting is set as arg(1)... meaning the fields belong to the comment nodes but the votes belong to the parent node. Very cool.
We've had clients who have requests like wanting to promote comments to the front page, or rate comments, or categorize comments etc. This module fills those needs.
The release says it is beta, and I stick by that, but it is worth noting that this beta code probably serves 5 million page views a day or more on live (rockstar) websites.
-Robert
____________________________________________________________________________________ Never miss an email again! Yahoo! Toolbar alerts you the instant new Mail arrives. http://tools.search.yahoo.com/toolbar/features/mail/
Since it came up,
It comes up all the time. The problem here are nodeapi modules that will put an ungodly burden on the site. We talk with Moshe that maybe a nodeapi registry (per type, per op) could probably solve the problem. Well, that's trivial to code, so I did it. Then I went for the nodeapi modules to implement op 'registry' and stopped dead on my tracks. Not all modules can decide simply on type that they want or want not to operate on that type. Book and path are examples -- this means that while Robert might have one particular site which is not burdened by the multitude of the nodeapi queries -- Drupal core can't rely on this. Ideas are welcome. NK
On 4-Jun-07, at 10:26 PM, Karoly Negyesi wrote:
Ideas are welcome.
What we can do is that we make it mandatory that every single nodeapi module to become type based -- there is particularly little point in adding a path to a node type that will be a nodecomment.
Karoly asked me to summarize our discussion tonight: 1. A nodeapi registry makes it so you're not blindly calling 4000 functions per comment on a page. If entries are keyed by node type, you only call the specific hooks that need to be fired for that node type. 2. However, currently there are modules such as path, book, and upload which act on all modules indiscriminately. Forcing these modules to be enabled per-node-type would allow switching off the silly functionality that doesn't make sense for comments. But the UI will be icky... 30,000 radio buttons at admin/content/types/foo. :P 3. Touano of the DruBB group actually did some benchmarking of nodecomment module: http://groups.drupal.org/node/3550 ... however, Karoly pointed out that there are many optimizations that could be made to the code in order to get it core-worthy. So if we can solve 2 and 3, we're in business. ;) -Angie
thanks angie. lets go a step further. when we display a huge list of comments, we are really talking about 2 nodeapi ops: load and view. LOAD ---- We are getting to the point with schema where we can load a node with just a single query. It needs bit more work, but i think this is a solvable problem for D7. VIEW ----- Some versions of the node_rendering patch had a 'style' whereby nodeapi 'view' op was skipped. That might be useful here. Otherwise, I think we need to look at each slow nodeapi op and accelerate it, or make it configurable by type. I am encouraged that Robert's sites are working fine with nodecomment. -moshe Angela Byron wrote:
On 4-Jun-07, at 10:26 PM, Karoly Negyesi wrote:
Ideas are welcome.
What we can do is that we make it mandatory that every single nodeapi module to become type based -- there is particularly little point in adding a path to a node type that will be a nodecomment.
Karoly asked me to summarize our discussion tonight:
1. A nodeapi registry makes it so you're not blindly calling 4000 functions per comment on a page. If entries are keyed by node type, you only call the specific hooks that need to be fired for that node type. 2. However, currently there are modules such as path, book, and upload which act on all modules indiscriminately. Forcing these modules to be enabled per-node-type would allow switching off the silly functionality that doesn't make sense for comments. But the UI will be icky... 30,000 radio buttons at admin/content/types/foo. :P 3. Touano of the DruBB group actually did some benchmarking of nodecomment module: http://groups.drupal.org/node/3550 ... however, Karoly pointed out that there are many optimizations that could be made to the code in order to get it core-worthy.
So if we can solve 2 and 3, we're in business. ;)
-Angie
We are getting to the point with schema where we can load a node with just a single query. It needs bit more work, but i think this is a solvable problem for D7.
Really depends on what we to achieve. If we say, one query to retrieve the nids of the nodecomments and then one query to load a node, then probably yes. You do not want to JOIN all this into one huge query, see the one-to-one tables considered harmful on why (keys can't span tables, filesort hell). And adding foreign keys might happen in D6, it's not a big deal :) So at best we have one more query per nodecomment compared to what we have now. That's better than the five or so I feared originally but still :)
Some versions of the node_rendering patch had a 'style' whereby nodeapi 'view' op was skipped. That might be useful here. Otherwise, I think we need to look at each slow nodeapi op and accelerate it, or make it configurable by type. I am encouraged that Robert's sites are working fine with nodecomment.
I am not. Look at http://groups.drupal.org/node/3550#comment-10454 -- there are few nodecomments per node. And whatever you do, it'll be slower than just slapping the filtered comment body to output. However, I am not too afraid of this part -- we can overcome these problems. So it seems the next step is adding foreign keys to schema and bench the outcome. Regards, NK
Quoting Karoly Negyesi <karoly@negyesi.net>:
Ideas are welcome.
You mention book as a stumbling block. I can envision content types of book, chapter, section; there may be more but I'll limit to these three for the discussion. I create content for book which gives a high level view of the book and then I create child chapters which may have section children. Sections themselves may have section children. The content type relationship mapping table maps the child to the parent and the order (weight) of the child. I can then allow a content type I'll call comment to be added by others to the section, chapter or book as I choose. Earnie
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Quoting Karoly Negyesi <karoly@negyesi.net>:
Ideas are welcome.
You mention book as a stumbling block. I can envision content types of book, chapter, section; there may be more but I'll limit to these three for the discussion. I create content for book which gives a high level view of the book and then I create child chapters which may have section children. Sections themselves may have section children. The content type relationship mapping table maps the child to the parent and the order (weight) of the child. I can then allow a content type I'll call comment to be added by others to the section, chapter or book as I choose.
Looking at what I have written I can now envision that content types should be controlled such that the chapter content type can only be a child of the book content type and the section content type can only be a child of chapter and itself. Earnie
This patch: http://drupal.org/node/146425 moves the book module quite a bit closer to what you're suggesting. -Peter On 6/5/07, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Earnie Boyd <earnie@users.sourceforge.net>:
Looking at what I have written I can now envision that content types should be controlled such that the chapter content type can only be a child of the book content type and the section content type can only be a child of chapter and itself.
Earnie
participants (10)
-
Angela Byron -
David Strauss -
Earnie Boyd -
Karoly Negyesi -
Moshe Weitzman -
Peter Wolanin -
Robert Douglass -
Vivek Puri -
William Smith -
Wim Leers