Hello! I created a module which is similar in concept to customreports, yet takes a different approach, and wondered if I should start my own project, or merge it with yours. It basically provides a simple hook for modules to generate and optionally store their own downloadable CSV reports with a common UI.
If you're interested, take a look at the attached module, throw it into a test site, and look at the README.txt for instructions on how to use it.
I could go either way. I'm happy to create a module at the namespace of "custom_reports", and I'm equally as happy to become help maintain customreports and merge the two modules. They seem close enough in scope, and they should work together to give users and module developers easier tools to generate reports (which I frequently find easier to do in a custom fashion than trying to smash the requirements into Views).
Comment | File | Size | Author |
---|---|---|---|
#2 | custom_reports.zip | 10.29 KB | joelstein |
custom_reports.zip | 9.39 KB | joelstein |
Comments
Comment #1
geerlingguy CreditAttribution: geerlingguy commentedThe UI would be very helpful to me.
Comment #2
joelstein CreditAttribution: joelstein commentedHere's the latest version of my Custom Reports module. Please give it a quick look (especially the README.txt), and let me know if you would like me to merge this into your module. If not, I'll create my own.
Comment #3
geerlingguy CreditAttribution: geerlingguy commentedLooking over everything, there are some very useful features in joelstein's version; I would really like if the modules could be merged, rather than having another 'competing module' (not really, but that's how many would see it) on d.org.
Comment #4
snufkin CreditAttribution: snufkin commentedI have a few problems with this.
First of all I don't really see how the features provided with this module would conflict with the ones in customreports. Customreports allows you to get the results of sql queries from nodes into cvs files. Your module provides an API so it can list all reports provided by a module (from the code) downloadable in one location. The reports coming from customreports are done in the node level, so I am not sure how we would go, or want to go with an integration.
Secondly, your modules is an API module. The best would be to keep it at that. Provide an api, no features as a separate project.
Third, the namespace. customreports holds this namespace, and while you could create a project called custom_reports I would ask you not to as it would just make people confused about what the respective modules offer, which one they want. Instead I suggest you rename the module, perhaps to reports_api?
I can imagine customreports leveraging your API later on to somehow provide all its reports in one location, but I don't think merging the code is a good idea.
Comment #5
joelstein CreditAttribution: joelstein commentedThe features don't conflict, you are correct. But since the purpose of the two modules are nearly the same, I thought it would be useful to merge them into one, so that users aren't confused as to which custom reports module to download. I'm happy to do all the heavy-lifting to merge the two together, and to jump on board as a maintainer as well.
If you still disagree with me, I'll give up, and start my own module. Thanks.
Comment #6
snufkin CreditAttribution: snufkin commentedI've asked a_c_m to take a look at this issue and comment, I couldn't grant you commit rights even if i thought that merging is a good idea.
I am not trying to tell you off, dont misunderstand. I am looking at the most effective development path here and I don't see the benefit in merging for either of us. You could maintain your module more easily if you dont have to deal with all the other functionality that this module provides, and the same applies to us. And yes, this module might benefit from your API, but we could as well just ask for your module as a dependency.
All I would ask is that you chose a better/different name to avoid the confusion.
Comment #7
a_c_m CreditAttribution: a_c_m commentedSorry for being a bad module maintainer - i will take a look at this this week and get back to you. For some reason this never ping'ed in my queue.
Comment #8
a_c_m CreditAttribution: a_c_m commentedOk, so looked over the code and more or less came to the same conclusion as snufkin. The module looks like a nice api way of storing reports and it would be great if customreports could be extended to use its functionality if the api module is installed (but i dont think it should be a dependency).
If you were interesting in improving customreports to work with your module, i would welcome that - however i think, again as snufkin said, your module is better named reports_api or something like that and left as an API for modules like customreports to use.
I too would ask is that you chose a better/different name to avoid the confusion and namespace pollution.
Comment #9
apadernoI am closing this issue since the project doesn't have versions for supported Drupal versions.