Re: [drupal-devel] forum.module dependent on comment.module
On Fri, 04 Mar 2005 19:33:43 -0600, Mark <mark@nullcraft.org> wrote:
There has been discussion about implementing comments as nodes. What would the difficulties be with such a scenario? If comments were nodes, then it would be trivial to specify additional node types that could be used as comments (files and images, anyone?). I think if relativity module were simplified and a lot of the more advanced features were moved into separate module, just leaving the relationship management part, this would be quite feasible.
I'm curious to see what others think about such a scenario.
I tried to steer away from the comments-as-nodes discussion, but you seem to have stumbled right into it :P It basically means some major rewriting, and there is value in keeping comments as a separate content type, I think. I'm not willing to dive into this can of worms right now. -- Boris Mann http://www.bryght.com
On Fri, 4 Mar 2005, Boris Mann wrote:
On Fri, 04 Mar 2005 19:33:43 -0600, Mark <mark@nullcraft.org> wrote:
There has been discussion about implementing comments as nodes. What would the difficulties be with such a scenario? If comments were nodes, then it would be trivial to specify additional node types that could be used as comments (files and images, anyone?). I think if relativity module were simplified and a lot of the more advanced features were moved into separate module, just leaving the relationship management part, this would be quite feasible.
I'm curious to see what others think about such a scenario.
I tried to steer away from the comments-as-nodes discussion, but you seem to have stumbled right into it :P
Congrats. ;)
It basically means some major rewriting, and there is value in keeping comments as a separate content type, I think. I'm not willing to dive into this can of worms right now.
What it really means is that there will be more nodes. On drupal.org the number of entries into the node table will about double. As long as nobody cares enough to provide hard test data to show Dries and us others that there is a negligible impact on performance this discussion is just hot air. Doing 50 node loads on a single page load can be fun. In contrast, the comments get pulled out in one single query. Cheers, Gerhard
Gerhard Killesreiter wrote:
On Fri, 4 Mar 2005, Boris Mann wrote:
On Fri, 04 Mar 2005 19:33:43 -0600, Mark <mark@nullcraft.org> wrote:
There has been discussion about implementing comments as nodes. What would the difficulties be with such a scenario? If comments were nodes, then it would be trivial to specify additional node types that could be used as comments (files and images, anyone?). I think if relativity module were simplified and a lot of the more advanced features were moved into separate module, just leaving the relationship management part, this would be quite feasible.
I'm curious to see what others think about such a scenario.
I tried to steer away from the comments-as-nodes discussion, but you seem to have stumbled right into it :P
Congrats. ;)
Yay me! What do I win? :P
It basically means some major rewriting, and there is value in keeping comments as a separate content type, I think. I'm not willing to dive into this can of worms right now.
What it really means is that there will be more nodes. On drupal.org the number of entries into the node table will about double. As long as nobody cares enough to provide hard test data to show Dries and us others that there is a negligible impact on performance this discussion is just hot air.
Doing 50 node loads on a single page load can be fun. In contrast, the comments get pulled out in one single query.
This was pretty much my response to suggestions that comments be nodes. Even if some crafty SQL guru could pull up a whole thread of comment nodes all in one efficient query, each would still need to be fully materialized through nodeapi, have access checked, etc. As nice as it would be to have a homogenous view of your content, the physical burden of loading and managing it would be significant. This would be perfectly acceptible on high-feature/low traffic sites such as many of the tools I've been building lately, but high traffic sites would most likely burn a hole in the rack they were mounted to :) -Mark
Op zaterdag 5 maart 2005 03:02, schreef Gerhard Killesreiter:
What it really means is that there will be more nodes. On drupal.org the number of entries into the node table will about double. As long as nobody cares enough to provide hard test data to show Dries and us others that there is a negligible impact on performance this discussion is just hot air.
This is not an argument IMO. A website should always scale. And simply chopping things up might wiork for some cases, but is not an overall solution. Lets take an example: A site with thousands of articles and 10 of thousands of weblinks. If that starts to perform less good, the solution is not to pull weblinks out of the nodes system and create its own system, but the solution is to make overall node performance (AND maintanability!) better. With the useability improvements the issue of maintainability of large amounts should be solvable.
Doing 50 node loads on a single page load can be fun. In contrast, the comments get pulled out in one single query.
if ever we go into comments as nodes, we must create some custom and improved queries indeed. I am thinking in lines of db_get_child_nodes($nid), which would return an array with all children nodes (comments) from a node. I will not take such a project on me, BTW :) Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
On Sat, 5 Mar 2005, Bèr Kessels wrote:
Op zaterdag 5 maart 2005 03:02, schreef Gerhard Killesreiter:
What it really means is that there will be more nodes. On drupal.org the number of entries into the node table will about double. As long as nobody cares enough to provide hard test data to show Dries and us others that there is a negligible impact on performance this discussion is just hot air.
This is not an argument IMO.
Oh, it sure is. Performance is always a good argument.
A website should always scale.
In an ideal world.
And simply chopping things up might wiork for some cases, but is not an overall solution.
I am not convinced that comments as nodes makes too much sense anyway. The only thing I think that could be usefull for comments that they currently have not are file attachements.
Lets take an example: A site with thousands of articles and 10 of thousands of weblinks. If that starts to perform less good, the solution is not to pull weblinks out of the nodes system and create its own system, but the solution is to make overall node performance (AND maintanability!) better.
Well, there is only so much you can do from Drupal. If your database doesn't scale anymore, you need to reconsider things. You can of course always buy a faster computer, but this will not always be popular.
With the useability improvements the issue of maintainability of large amounts should be solvable.
I am not talking about maintainability.
Doing 50 node loads on a single page load can be fun. In contrast, the comments get pulled out in one single query.
if ever we go into comments as nodes, we must create some custom and improved queries indeed. I am thinking in lines of db_get_child_nodes($nid), which would return an array with all children nodes (comments) from a node.
If you want full nodes (nodeapi etc), this is not going to work. At least not without caching. If you don't want full nodes, we can just leave comments comments.
I will not take such a project on me, BTW :)
Maybe we should stop talking then. Cheers, Gerhard
What it really means is that there will be more nodes. On drupal.org the number of entries into the node table will about double. As long as nobody cares enough to provide hard test data to show Dries and us others that there is a negligible impact on performance this discussion is just hot air.
Doing 50 node loads on a single page load can be fun. In contrast, the comments get pulled out in one single query.
There are actually many more comments than nodes on drupal.org: 30172 comments, 17281 nodes. Furthermore there are 23247 issue followups which I believe are not in the comments table. Comments have a simplicity to them that makes it attractive to treat them separately. Should node access apply to comments? Should you be able to nodeapi a comment? Should comments be able to go into the book outline? Plus, you'll essentially be performing two distinct kinds of queries on that table: 1) Fetch a node, 2) Fetch a node's associated 'comments' (also nodes). Most queries would have a type = "comment" or type!="comment" check on them anyway (or "comment = true/false" if you want any node as a comment), plus a bunch of other fields and code that would be checked depending on that value. You'd be throwing together two distinct things into one big table, which is rarely a good idea. All of this sounds like a lot of work with no really good benefits in the long-run. Steven Wittens
Op zaterdag 5 maart 2005 19:14, schreef Steven Wittens:
All of this sounds like a lot of work with no really good benefits in the long-run. Actually this is a non-discussion. One that needs to be held every month or so. But never ever will anything turn out of it,, unless someone actually makes it (and then will prove it to be much better ;P)
So lets end that discussion here ;) Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Op zaterdag 5 maart 2005 19:14, schreef Steven Wittens:
All of this sounds like a lot of work with no really good benefits in the long-run.
Actually this is a non-discussion. One that needs to be held every month or so. But never ever will anything turn out of it,, unless someone actually makes it (and then will prove it to be much better ;P)
So lets end that discussion here ;)
Boris is a master manipulator of people. He tempted this whole discussion so that he could see it unfold without being personally involved. Boris, you have my respect and admiration ;) -Mark
Actually this is a non-discussion. One that needs to be held every month or so. But never ever will anything turn out of it,, unless someone actually makes it (and then will prove it to be much better ;P)
So lets end that discussion here ;)
Do not end it. The original problem was that casual drupal admin switches on forum but no comments. I proposed that forum_help must drop an error message in this case. I got no replies on this. Regards NK
Negyesi Karoly wrote:
The original problem was that casual drupal admin switches on forum but no comments.
I had someone fighting with exactly this. He spent more than an hour setting up forums (taxonomy nightmare), managed to post forum topics, but never managed to post follow ups. In the end, he phoned me for support. Of course, it took no more than 30 seconds to diagnose and fix the problem. Regardless, a pretty frustrating experience. The point? For us it's obvious that you have to enable the comment module to use forums, but for people that are not familiar with Drupal it is not. Those people assume that the forum module is self-contained.
I proposed that forum_help must drop an error message in this case. I got no replies on this.
I'd add a check in forum_admin() rather than in forum_help(). Feel free to share a patch. -- Dries Buytaert :: http://www.buytaert.net/
I'd add a check in forum_admin() rather than in forum_help(). Feel free to share a patch.
I already told this, again: if it is in forum_admin then a) go to modules admin b) enable forum c) go to forum admin d) jolly good! an error message! back to modules admin e) enable comments f) finally! forum works. instead a) go to modules admin b) enable forum c) an error message show: you need to enable comments. Or even even better, do it for the administrator. Error message "A forum is a forum type node and followups are comments. Because of this, comments is also enabled.". Nice and easy. I'll whip up a patch... Regards NK
Dries Buytaert wrote:
Negyesi Karoly wrote:
The original problem was that casual drupal admin switches on forum but no comments.
The point? For us it's obvious that you have to enable the comment module to use forums, but for people that are not familiar with Drupal it is not. Those people assume that the forum module is self-contained.
Pardon me if I'm coming in late to this discussion, but... I know that many of the modules that I write depend on other modules to be installed and enabled. Some of them may optionally take advantage of other modules if they happen to be installed. What about having some hook for specifying required and optional modules that compliment a given module? The dependencies could be used by an automated installer as well. For instance, filestore2.module could have some means (outside of the README.txt, of course) of specifying that fscache.module must be installed in order for it to work. The admin/modules page could display a warning when a required module was not enabled. Optional modules that aren't enabled could be suggested at this time as well. I could see this as a hook_dependencies that looked like: function filestore2_dependencies() { return array('required'=>array('fscache'), 'optional'=>array('taxonomy','comments')); } This would make it very obvious what references a module had, assuming the hook was current. Ideas? -Mark
Ideas?
For now, a simple mechanism is intoduced: hook_depens returns a string or an array with the name of required modules. The patch is at http://drupal.org/node/18447 It emulates a user ticking in the dependency modules and if such an emulated tick happened, it issues another system_listing_save. It's neither forum_help nor forum_admin that omits an error message but system_listing itself. ChX
participants (7)
-
Boris Mann -
Bèr Kessels -
Dries Buytaert -
Gerhard Killesreiter -
Mark -
Negyesi Karoly -
Steven Wittens