- Posts: 36
- Thank you received: 0
custom reports and custom pages
What would be the best way to generate custom reports and custom pages from the data in lime? What I'm trying to do is as follows:
1. create custom lists of responses (for now just to display or export the respondents who passed screening and those that failed.)
2. create a translation page for submitted responses (both closed and open ended).
3. on the same page, a coding/tagging interface for translated responses to categorize them for reporting.
4. create custom reports based on the coded responses.
I'll move this thread to the "Development" forum, I think it's better to discuss it there.
Mit freundlichen Grüßen/Best regards,
Perhaps the YII architecture or the API will make custom reporting easier as well.
Sounds like a good configuration option: give users the ability to specify whether to use SGQA or Qcode naming in the database. That's an easy change for the database, but would have broader implications for the statistics reporting and quotas.
We'd likely need to either change the variable names for the "reserved" fields in the database (like sid and submitdate) so that Qcode names don't overwrite those values.
The bigger implication is for EM, but EM already supports question codes. I know a lot of JS exists using the SGQA naming, although I don't understand how those surveys are ever able to be moved.
I'm hoping that reports will be rewritten using MVC architecture anyway. I still haven't gotten a chance to dive into the Yii version yet. Is that being actively developed at the moment?
- Security: Not sure if/how to integrate LS tokens and security with an external app.
- Database: "Select * from <results_table>" gives you back a list of SGQA indexes to your data. You can write a custom report based on that, but then if you ever move it, or copy the survey, or whatever, the report won't work.
Another approach might be to use some more tables, e.g. one table for the raw answer data with an ID pointing to table 2 which holds general information on related SID, GID, QID, parent_QID and the like. You can even have a thrid table with all the metadata like related token, submitdate, ref. URL, ...
In general it all depends on how you want to analyse data, which layout a certain tool needs to rely on and the like.
Best regards/Beste Grüße,
Dr. Marcel Minke
(Limesurvey Head of Support)
Need Help? We offer professional Limesurvey support
Part of the issue is figuring out how to associate reports with specific surveys. I guess it could be done the same way that token attributes are done, a new field in the survey table that's a list of reports. The UI could then render that list for those reports.
For reporting, I prefer using Twig, and see that it can be easily integrated with Yii ( yiiext.github.com/extensions/twig-renderer/index.html ). Not sure the best way to get community buy-in that having Twig as an option is a good idea. I resisted it for a long time ("After all, php IS a templating language!"), but once I adopted it I became a huge fan, and it makes the MVC architecture easier to follow.
Eventually I'll figure out git and branches and just add it to my repository and do a pull request once it's working and can be justified.
Mazi wrote: How about an alternative approach: Convert response data in Limesurvey into a different table structure (one row per response with related data like SID, GID, QID, ...). This way you can get rid of the strange column naming at Limesurvey and can easily query data fro a certain survey, group or question.
Here is how I would recommend doing this. I've used this Entity-Attribute-Value approach for a decade, and performance is excellent (despite running on a low-end Amazon EC2 instance and having a 17 GB MySql database with over 200,000 responses and 70 million rows of data).
The other advantage to this approach is that it becomes simple to add repeatable groups. For example, if you have a group called 'child' with 3 questions, name, gender, birthday, and you want this to be repeatable. Currently after a lot of typing and renaming of fields, you end up with a big table with fields like child1_name, child2_name. Reporting on this is a mess.
But with Entity-Attribute-Value, you could have unrestricted repeatable questions, AND when you report on it, you'd be able to treat each "child" as an independent entity, not looping through to some artificial maximum. That is, you could rewrite a report that says "give me a list of all the children in this survey's responses."
Is this a possibility for 2.0? If so, I'd love to participate in the design discussion, we had done some preliminary work for our survey system, and I have some thoughts on integrating timing, survey versions, and the like.
It would be great to have you involved.
2.0's feature list hasn't been locked down yet, so anything goes. Once we pass the lock phase, we'd need to focus on 2.1.
So, perhaps the best place to start would be for you to create a wiki page with a proposed data model so that we can discuss it. I'm especially interested in your ideas for unrestricted repeating groups.
EAV with qcode naming could also help another topic you raised - importing answers from one survey into a new one without having to worry about SGQA naming.
There would probably be things like order, prompt, advanced, and maybe some validation rules, whatever.
But then it's active in the interface, without having to change the underlying code! You'd access it with some sort of method call, e.g. $survey->getAttribute('custom_reports').
Where the attribute is stored would depend on things like access speed, filtering and sorting. So expiration_date and is_public would probably continue to be stored in the surveys table (to make the query faster and easier) but custom_reports would be in the attribute data table (something like survey_attribute_data, or survey_attributes).