Dynamic Comments is being developed as the first step into a front-end
collaborative interface on Drupal. The module is used to flag portions of text
on any given node and make comments on the selection. The system saves your
comment and its position on the document and allows other users viewing the same
node to see your comments in almost real time.
IMPORTANT
----------
There is a comprehensive guide on installing and configuring, as well as using this module in the README.txt file. Please read this guide carefully before implementing the module.
Link to project: http://drupal.org/sandbox/mariano/1538470
Git repo: http://git.drupal.org/sandbox/mariano/1538470.git
Will create a D7 version once the project has been reviewed and promoted :)
Thanks!
Comments
Comment #1
patrickd commentedwelcome,
As most people rather look on project pages instead of readme's I'd suggest you to put the installation and usage instructions also onto your project page, may also have a look at the tips for a great project page. README.txt conventions: guidelines for in-project documentation.
I've seen you already used the automated review (http://ventral.org/pareview/httpgitdrupalorgsandboxmariano1538470git), great,
if you got questions on some of the left issues, feel free to ask.
We do really need more hands in the application queue and highly recommend to get a review bonus so we can come back to your application sooner.
regards
Comment #2
Mariano commentedThanks patrickd,
The left issues are just warnings on 4 lines that go over 80 chars by 20 characters max, I will leave those as is for now, as they make the code more readable. The other warnings regarding the use of $_POST are covered by using a token, although a more in depth review is very welcomed.
I can copy and paste my readme file to the project page, although by doing this I find that the project has now 2 docs places that need to be maintained instead of only one. Would be nice to have an automatic pulling of the README file contents to the project documentation page, since the README file is mandatory :)
I will be looking into the review bonus to speed up the process and to help out with your great work. Thanks for the suggestions!
Mariano
Comment #3
luxpaparazzi commentedAutomated review:
This automated report was generated with PAReview.sh, your friendly project application review script. You can also use the online version to check your project. Get a review bonus and we will come back to your application sooner.
Comment #4
luxpaparazzi commented1. IMO: You have many ugly blank lines, I would recommand removing them for better readability.
2. You should use t() around the message, for allowing translations to work.
3. You don't need $message above, just put it into the function.
4. you should put html into theme functions or files:
5. You should use theme functions or .tpl files:
6. don't use "code-separators" :
7. Where does the following comment belong to:
8. First line does not male sense:
---
The response time for a review is now approaching 4 weeks.
Get a review bonus and we will come back to your application sooner.
See: http://drupal.org/node/1410826
You could for example start by evaluating my own project:
http://drupal.org/node/1302786
Comment #5
Mariano commentedluxpaparazzi, thanks for the feedback. I've removed some of the white lines to improve the testing experience. Regarding number 4, it's JS... I am following ctools' styling for html templating... Is there a different way I should be using?
Comment #6
Mariano commentedComment #7
luxpaparazzi commentedyou could maybe take a look at http://engineeredweb.com/blog/11/5/javascript-theme-functions-drupal/
Comment #8
brazorf commentedHello Mariano,
this is a sexy module imho, you got a nice idea.
Did you forget t() on dynamic_comments_settings.inc:62-67? :)
I have just some comments on computation.
In your nodeapi hook, 'view' branch, you are operating on your module's allowed content types. You could of course check this condition before trying anything else, because that's mandatory: since you're operating on every node view this could save some elaboration, but this could be just a silly thing.
What could impact more is the file_exists() question on line 67 and 75, and every drupal_add_* coming next: remember that your nodeapi-view hook is performed on each page load, and every file_exists trigger a potential unnecessary disk (or cache...whatever) hit. You have edge to optimize your module (remember M operation * 1 page load * N concurrent users could grow up naughty)
Keep on the good job
Regards
Comment #9
Mariano commentedHey, brazof, thanks for the feedback.
I totally forgot the t() functions there! nice catch!
Reviewing your concerns about performance, I believe you make a good point. However, the logic is wrapped on a permissions check on the user too. The way I see it, when a node is about to be viewed, I have two relatively inexpensive checks guarding the most expensive ones. For instance, if the user has the necessary permissions to use the module AND if the node type is in the list of allowed types, only then I perform file check and css and js inclusion. I have to check if the files are there because I do not own them, they are 3rd party. And obviously I have to add them at the module level and not info file because I need the user to do the work of downloading and installing them.
If used as recommended, the content type allowing for comments will most likely be only one, and the users allowed to use the comments would be editors, so the impact doesn't seem to be that high. If after all these conditions the file checking is still a concern, I can think of maybe checking at the setup level and saving a variable to use in the later checks, or even checking regularly on cron; but if the user deletes a necessary file between crons, or if the site doesn't have cron running (all real life possibilities) I could not avoid a 500 error on their site.
Thanks for the compliments on the idea, I have lots of plans for it once I come off the review process! :)
Comment #10
Mariano commented@luxpaparazzi
Awesome link, learned a lot. I've committed mods to the code to use the JS theme functions.
Thanks!
Comment #11
Rajan M commentedHi Mariano,
There are still code indentation issues:
http://ventral.org/pareview/httpgitdrupalorgsandboxmariano1538470git
(http://ventral.org is still under development and changed frequently hence the quality of automated reviews can vary from day to day. :( )
Manual review :
#1 Have a look at http://drupal.org/project/libraries to see how you can integrate libraries in a better way.
#2 In dynamic_comments_settings.inc, you are building error messages (list items) for drupal_set_message(), you could use drupal_set_message() for individual message.
#3 I think your module does not delete it's variables on uninstallation.
#4 It is recommended that for admin settings you should use file name convention like [modulename].admin.inc
#5 specific permission names as 'delete single comments', should at least contain your module name.
#6 In some cases you can save extra variables eg:
Instead
Is better way.
I will have to look into the deep ...
Comment #12
Mariano commentedHi Rajan,
I've followed your advice for items #2 to #6 and I am committing the changes right now.
For the libraries module integration, I'd like to keep dependencies to a minimum, so if it's an option, I'll opt out. As for Ventral, the issues are lines passing 80 chars. For these few lines passing 80 chars I prefer to keep them readable than to stick to that rule.
Thanks
Comment #13
Mariano commentedComment #14
brazorf commentedHello there,
it is a recommended practice to delete your variables in module uninstall hook.
See http://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/varia...
Anyway i think this module is nearly rtbc as far as i can see.
Regards
Comment #15
Rajan M commentedHi Mariano,
You should fix those issues listed in http://ventral.org/pareview/httpgitdrupalorgsandboxmariano1538470git since these are code standards. Exceptions are only allowed in case if 'pareview' throwing any wrong issue.
Also please update your code according to the manual review.
Thanks,
Rajan
Comment #16
Mariano commentedThanks brazorf, I will implement the var deletes as soon as I have some time to devote to the module :)
Comment #17
Mariano commentedHi Rajan,
I am planning on updating the code as soon as I get a day off! thanks!
Comment #18
klausiClosing due to lack of activity. Feel free to reopen if you are still working on this application.