Wednesday 23 March 2011 10:55:17 am

I have one main comment here : thanks for this post. Very informative, and probably the clearest return on experience on eZ Comments.

This portal uses eZ's content model to handle forums, allowing for the more advanced features you mentioned. But there was no other choice when building this portal, eZ Comments was not existing yet. If the usability of eZ Comments is very good, then enhancing it, where possible, based on your remarks, while keeping it a simple-to-install extension could be an idea.

Cheers,

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Thursday 24 March 2011 12:33:37 am

Thanx for this great article...i'll keep using my custom "insert & update" view called using ajax queries to handle any class client publication.

EZP is Great

Tuesday 29 March 2011 1:31:13 am

Very interesting topic. While I understand your needs, I guess for most websites, rating, threading and all advanced features are not really needed. So use the tool that fits your needs best.

I agree that for ezcomments to be an easy-to-use, ready out-of-the-box solution, a few things are still missing: the control panel with all the latest comments, search within comments, moderation (!). Of course anybody willing to add them is welcome ;-)

Otoh improving the basics of "content" management in eZ is also a good idea; I am thinking here especially about information collection, a powerful feature often underutilized (it needs better fetch functions, more event triggers, better management panels) that could basically do all that ezcomments does...

Principal Consultant International Business
Member of the Community Project Board

Thursday 31 March 2011 3:23:26 pm

Hello Marko,

Thank you for this interesting and valuable point.

I agree there is lack of functionalities like moderation/ bat-deleting/ comment management, etc, but from your post yes I think those are not what you want to talk(actually we have those functionalities in plan and there is a pull request for simple comment management already).

For the content model's perspective, I think this is an argument between flexibility and performance. eZ Comments's main value is really from performance's consideration(and usability with current ezp status), so if ideally ezp's model can solve the performance well or from your experience it performs good and easy to use(this is not easy to achieve for now and some time I guess) I don't much to oppose.

But think some special comments-oriented functions( performance related and usability):

- what if we need a very high traffic commenting need (for instance if some websites have many comments in every seconds and even we want comments shown in real time), ezp's cache mechanism can not reach this easily.

- before there are easy-use cms features using ezp's model(like forums, comment, anonymous subscribers), ezcomments is still a easy way for commenting. Personally I really hope the community project can do much in those usability.

PS: Someone even suggested that ezcomments can be extended to be a forum - this is technically possible but this topic is also arguable.

I suppose to add more api documentation when I get time so people can get the hook and extend ezcomments (for instance voting), and actually we even tried a AJAX version in the beginning :). Actually the idea of extending ezcomments is a bit tricky - like implementing similar functionality to ezp again, but I think some small features are still worthy :).

@Marko

I think for quite some time, that's the way to go. so if you have some in real project, please share your ideas..

Theoretical point I think I agree (theoretically meta model+model is always good :))..

eZ Comments: http://projects.ez.no/ezcomments
twitter: http://twitter.com/xiongjie

Tuesday 05 April 2011 6:59:07 am

OK, here we go...

First thoughts about this...

In the case you have described, most possible usages can be presented by two pretty much representative cases:

• a) you have at most 10 comments per article (in average)
• b) you have more than 100 comments per article (in average)

The case a) means that several articles are published every 10 seconds. In such a case you'll have a big performance impact anyway, wether you put your comments in a separate table or not.

Yes, there is a 1/10 ratio between articles and comments but articles usually have more than 10 times more content than comments. So publishing few articles every 10 seconds will probably have the same (or even bigger) performance impact than publishing comments every second.

Of course, some real world measuring should be done in order to be sure abotu this, but I have a hunch that in this case not much performance benefits will be gained by putting comments in a separate table.

In the case b) we should wonder if the eZP + eZ Comments is the right solution. As much as i love eZP and everything that comes with it, we have to be real – it's not a solution for everything. On such a site, with more than 100 comments per article which is using eZP and eZ Comments you'll probably have to do one of the following:

• rethink your choice and whether eZ Comments + standard eZ Publish is the right solution. Since you are dealing with something far more complex than just an article commenting system
• fire your site redaction and hire users as editors/journalist. Since they are obviously generating more content than the current editors :)

Because in the case b), comments will make a far more greater part of the site's content, therefore they should really be treated as content. On such a site you'll probably have the need for most of the features that come from eZP content model. For example a threaded comments view would be a must on such a site. Or sorting articles on different criteria. Or far better comments administration possibilities.

Also I believe that in extremes of the case b) (e.g. more than 3000 comments per second) most developers would use a completely custom solution, probably using eZ components and eZP PHP classes. Or they wouldn't use eZP at all.

Second thoughts about this...

Instead of reinventing the wheel why not make the existing wheel go faster? Why not improve the eZP publishing mechanism so that it can handle such a scenario. Some improvements were made in eZP 4.5, especially with "asynchronous publishing" (can't wait to try it), but it can go further more... There could be a possibility to skip some parts of the publishing proces in some cases in order to speed it up. So the comment/add function could be implemented by publishing a content object of the Comment class while skipping uneeded parts of the standard publishing process.

As for the "displaying comments in realtime" you can make a special fetch function that fetches comments objects using the eZPersistentObject's functions and that creates SQL queries only on the ezcontentobject table. With the table being indexed on class ID field, the performance of this fetches should be as good as when fetching comments from a separate table.

For now, my opinion stays the same – the eZ Comments should be rewritten.

I'm preparing the list, stay tuned...

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth