Hello!
I would first have to thank you for your effort in making custom questions available via plugins. I wrote this topic a year ago (
www.limesurvey.org/en/forum/future-featu...s-with-a-php-plug-in ) and it is now much closer to reality.
I have checked the file \limesurvey\application\helpers\common_helper.php [v2.05] and it still contains hard coded questions.
I would suggest you to refactor the code by moving all of the current built-in questions into plugins. In the process you will learn what is needed to reimplement all of the current functionality via APIs. If you don't do this, there will always be first class (built-in) and second class (pluggable) question types.
I think the plugin would have to be a multifile solution, put into a separate directory:
- PHP template + custom CSS for front end (what people see when answering surveys)
- PHP template + custom CSS for back end (what admins see when creating surveys)
- PHP logic files; I'd like to see them implemented as interfaces (inheritance and other OO stuff); see
php.net/manual/en/language.oop5.interfaces.php . Don't drop OO features, because of supporting 5.2 and earlier (they are EOLed anyway).
Maybe the logic could be in three parts:
- front-end only logic file
- back-end only logic file
- common front- and back-end logic file
Basically my end use scenario is to get question options from a SQL server, they could be different for different groups of respondents (tokens). One of the API calls could be: get me info for this token (name, lastname, group)
Don't be afraid to break SQL schema compatibility. I wrote my own software that imports data directly from lime sql tables, but I'm not that much bothered if I have to do some adjustments to the code.
Question types have to have a more descriptive designation, not only a capital letter. I suggest vendor.questiontype. For the built-in questions it could be "lime.array10" or "lime.multiplenum"
Then there's the SQL schema problem. I think there should be an API call to the question plugin to declare what MySQL data types it needs:
- colname
- coltype
- optional description
- storage type (SQL or file; could be merged with coltype; if coltype=="FILE", then it's file based)
- optional function pointer for formatting (printing) output, for example printing floating point numbers
- optional formatting function parameters
The function (specified by function pointer) is then called by the lime core with all of the above parameters and returns a printable output from SQL / file. It could also be a picture (PNG/JPG or HTML to be inserted into innerhtml placeholder).
When developing question types, there should also be an option to (easily) change the custom question type SQL schema (and delete the file storage).
The colname is prefixed in the SQL DB, but the API should be able to work with both full and short colnames. (the prefix should be available to the question type, if it needs to directly update the SQL DB, not via the built-in APIs).
Consider also file based storage. All you need is to create a directory and a generate a token based file name. Pretty much the same APIs could be used as with the SQL storage, only optional parameter "$storagetype='FILE'" would have to be specified, when creating SQL schema. Reading and writing to a LONGBLOB/TEXT and a file should be practically the same. If the respondent uploads a file, it is better to be saved to a filesystem than into an SQL blob.
That's pretty much it. I'll be happy to test the alpha builds.
Best regards,
Marsip
).
