Make ls_survey not depend on ls_answ

Hi Owen Barton !

Thank you for sharing your experience and custom code on the LimeSurvey Sync module.

I may think on your idea, but, at the first sight, I may not implement such feature.
The point is : when a survey node is created, it creates in the meanwhile the associated answers content type. The answer content types are declared into the ls_answ_info() function. That why the ls_answ module is needed when creating a new survey node. And it would be an error to declare it somewhere else [EDIT : That's not true on Drupal 7, see #4].

If I would implement your idea, I would need to add a checkboxe when the node survey is created asking if the answers content type has to be created or not but it would make no sense : answer content type is needed even if you don't use tokens or if you don't import answers because you need it to provide the limesurvey answer url : node/add/your_answer_content_type.

Furthermore, I don't understand why someone may want to enable the ls_survey module but not the ls_answ module... The ls_answ module can be enabled it won't change anything (even regarding performances). If you want to disallow to import answers you just need to disable the permission to view the correponding survey node.

The abstraction seems quite good to me, at least on that point.

Could you explain the interest to use the LimeSurvey Sync module without the ls_answ module ?

Ok, I understand your point of view now.

and also adds a lot of configuration and user interface clutter, and leads to a much more confusing user experience than necessary

Disabling the ls_answ module makes more sense. However, you don't need it because you are developing a separate module replacing it : it is not an usual case.

We are working on a separate module (which we will contribute, of course) to sync actual survey response data into tables to allow it to be efficiently analysed and charted with views

That an interesting feature ! I'm very curious about it.

(it would be possible to write views integration against the LimeSurvey tables directly, but they are structured in a way that would make many queries complex and slow).
We can't use ls_answ because it does not make the actual data columns available, and even if it did, storing it in node fields would get complex and slow very soon with large datasets.

I totally agree.

I do understand that you can enable ls_answ without actually running any sync - nevertheless it requires creating a new content type (that will never be used) for every survey

I said that the answer content type has to be declared into the ls_answ module but I was wrong concerning Drupal 7 : I explain why here :
The LimeSurvey Sync module was designed first for Drupal6. On Drupal 6, the only way to distinguish the Survey content type and the Answers content type was to set them into disctinct modules, using the $type->module value to detect which content type it was. On Drupal 7, thanks to the new 'base' colomn into the {node_type} table, we could declare both content types into the same module, distinguish them using the $type->base value.

From an abstraction point of view - if both modules really need to depend on each other, and ls_survey contains code that is really for ls_answ, then I don't see any purpose in actually making them separate modules at all

The LimeSurvey Sync includes 3 modules :
- limesurvey_sync (handle the synchronization setting page)
- ls_survey (handle survey content types)
- ls_answ (handle answers).
I have created 3 modules in order to make the code more clear (disctinct features into disctinct folders and modules). but I may keep them into distinct folders without creating distinct modules. It would be a better abstraction.
I may succeed in declaring the Answers content type into the Ls_survey module intead of the ls_answ module (only on the Drupal 7 version).

Your thread happens at the right time : I'm working on a new major version of the LimeSurvey Sync module (7.x-2.0).
For your information, this new version will :

• enhance the synchronization process :
  • more colomns into the {ls_answ} table,
  • giving the ability to simulate an answer import/synchronization without saving it.
• and redesign the language selection in a smarter way :
  • creating one answer content type per survey, including all limesurvey languages (instead of one answer content type per survey language for a specific survey),
  • and using the 'Translation' core module to handle translations.

I may include the new module hierarchy into this new major version.

I have not decided yet :

• if I group all 3 modules into 1 module (i will probably choose this way on the Drupal 7 version).
• or if I keep the ls_answ module into a distinct module, fixing the semi-required dependency (and not fixing it on the Drupal 6 version).

The update script from 7.x-1.x to 7.x-2.x will be quite difficult to create, regarding new changes :
- one module instead of 3
- one content type per survey.
I hope I will have time for this on march.

Hello Owen,

The v7.x-2.0 is available as an alpha.
There is only one module now.
it comes with many improvements.
More informations here.