Overview
(from Sandbox page: http://drupal.org/sandbox/ethanw/1369794)
The Counter API module provides a generic infrastructure for the creation of event counters that can be incremented, managed and displayed as needed by other modules. Use cases for this module include "action" counters which can display the number of users who have participated in a given site action and donation progress bars that show "amount to goal".
On it's own the Counter API module provides an administration interface for the creation and management of individual counters, as well as tools for the manual setting and incrementing of counter values. This package also includes a simple module allowing for the display of counter values within blocks and is now integrated with the Actions API.
Comparison with Existing Modules
While there are other modules that deal with "counters", they are almost universally with very specific counter types, usually dealing with site statistics.
Compared to the modules listed below, this module is aimed at supporting a wide range of use cases in which information that may grow over time is presented to site visitors. The use cases originally scoped were specifically those related to user engagement: SMS messages sent, petitions signed, etc., though the module could be used for a wide range of purposes.
- Counter: provides a block for presentation of site visit statistics, IP, etc. Not intended to support ad hoc counters like Counter API would.
- View Counter: is a more general tool than Counter, but intended for analysis of Node types and other entities integrated with Views, also not general purpose counter and does not support simple counter display for users of the sort that Counter API does.
- Stuff Counter: intended as a more general framework, but like View Counter is views based, and was never committed to the repo.
Roadmap
The current development priorities for this module are:
- Porting to Drupal 7
- Creation of additional display types for Counter Block, including "amount to goal" progress bar.
Reviews of Other Projects
| Comment | File | Size | Author |
|---|---|---|---|
| #17 | drupalcs-result.txt | 2.79 KB | klausi |
Comments
Comment #1
patrickd commentedYou got some coding standart issues (See http://ventral.org/pareview/httpgitdrupalorgsandboxethanw1369794git, you can use this site to re-test your self)
If you got any questions on that please ask!
Comment #2
drupalnetworks commentedReview of the 6.x-1.x branch:
Drupal Code Sniffer has found some code style issues (please check the Drupal coding standards):
This automated report was generated with PAReview.sh, your friendly project application review script. Go and review some other project applications, so we can get back to yours sooner.
Source: http://ventral.org/pareview - PAReview.sh online service
Comment #3
ethanw commentedThanks patrickd and drupalnetworks!
We'd run through Coder, but not DrupalCS.
Fixes for all standards issues identified by DrupalCS have been uploaded, with the exception of issues related to the CTools Export UI.
The Export UI API uses underscore notation for its classes and methods, not Camel Case. See ctools_export_ui.class.php and example reference implementation for API requirements/standards.
Coding standards issues that result from the Export UI specification are:
Given that these issues result from an established API specification, does this bring the module into sufficient coding standards compliance?
Is there a process for resolving conflicts between established API standards and coding standards, such as this one? Note that if this fix is not sufficient, the Views module is also not in sufficient compliance, due to views_ui.class.php.
Comment #4
ericduran commented@ethanwl, you can feel free to ingore the coding standard regarding exported code.
We have some open issues with ctools and also some in drupalcs in regards to best solve this problem.
Comment #5
ethanw commentedThanks @ericduran.
For reference, related tickets appear to be: http://drupal.org/node/1366844 and http://drupal.org/node/1339084.
Comment #6
Robertas commentedcounter_api.module:69 and similar places:
watchdog('action', 'Incremented/decremented counter %counter_name', array('%counter_name' => check_plain($context['counter_name'])));Here call to check_plain() is redudant, since using '%' placeholders is already checking for plain text.
Comment #7
ethanw commentedThanks Robertas.
I've removed both check_plain's in watchdog calls.
Comment #8
gregglesThanks for comparing to several modules.
How does this compare to http://drupal.org/project/sampler ?
Comment #9
ethanw commentedThanks for highlighting that module I missed, @greggles.
I have not used Sampler API to date, but reviewing the project description and code I think the primary difference is that Sampler API is intended to poll a data source periodically and store samples of scalar values at each poll time (not necessarily the current value). Counter API, on the other hand, tracks incremental changes to a value, and is meant to be called directly on each update, not via a periodic call.
I can see these modules having quite a happy life together, actually, with a Sampler periodically checking the value of a Counter to provide support for historical data display and such. I also think that some of the data storage abstractions used in (the much more mature) Sampler API could be good guidelines for Counter API as it develops.
That said, I do think they are different enough so that this module does not duplicate Sampler's functionality. Sampler API is structured very elegantly to support it's specific use case, and while it might be modified to work for a counter as well, I think this would involve extra complexity for users and likely not serve Sampler API's architectural approach much. Similarly, there will likely be a number of "increment-specific" optimizations and features to be integrated into the Counter API which would not fit for Sampler.
Comment #10
gregglesAgreed there's not much duplication there - I ask mostly because others will ask and it's important to have a good answer for them. It would be great if you could add a wiki comparing all these at http://groups.drupal.org/similar-module-review and then link to that from your project page.
Comment #11
ethanw commentedI've created a wiki page comparing a few other data collection modules here: http://groups.drupal.org/node/198813.
Comment #12
ethanw commentedRaising priority to Major since it's been a bit over two weeks awaiting a reviewer response, following process in http://drupal.org/node/539608.
Thanks!
Comment #13
ethanw commentedRaising priority to Major since it's been a bit over two weeks awaiting a reviewer response, following process in http://drupal.org/node/539608.
Thanks!
Comment #14
rade commentedmanual review of 6.x-1.x branch:
Get a review bonus and we'll get back to you sooner.
Comment #14.0
rade commentedFixed typo.
Comment #15
ethanw commentedThanks @Rade.
I've addressed all the issues you listed in the 6.x-1.x branch:
Note that I've also included links to 3 past review comments. I will try to pluck another project from the current Needs Review queue before marking this issue as high priority. Hope that helps!
Comment #15.0
ethanw commentedAdded links to past reviews
Comment #16
ethanw commentedProvided links to 3 projects reviewed as application for PAReview bonus. Note that 2 of these are currently open review issues. While I understand that this is contrary to the recommendations in the review guidelines, the older of these two is not especially active at the moment, and I do not anticipate either to require so much attention that they would make it difficult for me to review them in parallel.
Comment #16.0
ethanw commentedAdded new review comment to "Reviews of Other Projects" list.
Comment #16.1
ethanw commentedAdded other sandbox projects awaiting full project approval status.
Comment #16.2
ethanw commentedFixed typo.
Comment #17
klausiReview of the 6.x-1.x branch:
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.
You can ignore the coding standard issues for class/method names.
manual review:
Removing review bonus tag, you can add it again if you have done another 3 reviews of other projects.
Comment #18
klausiClosing due to lack of activity. Feel free to reopen if you are still working on this application.
Comment #18.0
klausiRemoved pending projects section: major one, Backbone, now has a few potential routes to full project-hood.
Comment #19
avpaderno