Project Ideas for GSoC 2012 - Revision history

C schmitz: Text replacement - "Expression Manager" to "ExpressionScript"

2020-02-11T13:40:20Z

Text replacement - "Expression Manager" to "ExpressionScript"

← Older revision		Revision as of 15:40, 11 February 2020
Line 162:		Line 162:
	----		----

	==Enhance ~~Expression Manager~~==		==Enhance ExpressionScript==

	Starting with LimeSurvey 1.92, all of the front-end (survey-taking) processing is now managed using ~~Expression Manager~~ (EM). EM implements a safe subset of PHP syntax so that authors can write complex equations. It is integrated into LimeSuvey to control navigation (branching via relevance), validation, and tailoring/piping of content. Although it is quite powerful, users are already asking for enhancements.		Starting with LimeSurvey 1.92, all of the front-end (survey-taking) processing is now managed using ExpressionScript (EM). EM implements a safe subset of PHP syntax so that authors can write complex equations. It is integrated into LimeSuvey to control navigation (branching via relevance), validation, and tailoring/piping of content. Although it is quite powerful, users are already asking for enhancements.
	#Add a GUI for ~~Expression Manager~~		#Add a GUI for ExpressionScript
	**Background: LimeSurvey has a nice GUI for building conditions, but it does not support complex equations such as those available within EM. EM does have robust syntax highlighting after an equation is saved, which makes it easy to fix any syntax errors. Hoever, users would like a GUI to ease authoring of equations.		**Background: LimeSurvey has a nice GUI for building conditions, but it does not support complex equations such as those available within EM. EM does have robust syntax highlighting after an equation is saved, which makes it easy to fix any syntax errors. Hoever, users would like a GUI to ease authoring of equations.
	**Strategy - use CodeMirror - see [http://bugs.limesurvey.org/view.php?id=5279 here]		**Strategy - use CodeMirror - see [http://bugs.limesurvey.org/view.php?id=5279 here]
Line 219:		Line 219:
	'''Skills'''		'''Skills'''

	PHP, SQL, PHP Debugging (e.g. xdebug), Yii, LimeSurvey's ~~Expression Manager~~ and code-base in general		PHP, SQL, PHP Debugging (e.g. xdebug), Yii, LimeSurvey's ExpressionScript and code-base in general

	'''Difficulty'''		'''Difficulty'''
Line 241:		Line 241:
	***Add option for Entity Attribute Value data model for data collection (which can support unlimited number of columns. See details [http://bugs.limesurvey.org/view.php?id=5289 here].		***Add option for Entity Attribute Value data model for data collection (which can support unlimited number of columns. See details [http://bugs.limesurvey.org/view.php?id=5289 here].
	#Memory and Code Optimization		#Memory and Code Optimization
	**Background: LS loads the survey definition data model into several different data structures, such that it uses at least twice as much storage as it really needs. ~~Expression Manager~~ now holds all of the instrument definition data, so the other data stores are no longer needed.		**Background: LS loads the survey definition data model into several different data structures, such that it uses at least twice as much storage as it really needs. ExpressionScript now holds all of the instrument definition data, so the other data stores are no longer needed.
	**Strategy		**Strategy
	***Remove need for buildsurveysession() - gap analysis to add in any missing content to EM		***Remove need for buildsurveysession() - gap analysis to add in any missing content to EM
Line 289:		Line 289:
	'''Skills'''		'''Skills'''

	PHP, SQL, PHP Debugging (e.g. xdebug), Yii, LimeSurvey's ~~Expression Manager~~ and code-base in general, Load testing tool (e.g. webload), PHP Profiler		PHP, SQL, PHP Debugging (e.g. xdebug), Yii, LimeSurvey's ExpressionScript and code-base in general, Load testing tool (e.g. webload), PHP Profiler

	'''Difficulty'''		'''Difficulty'''

C schmitz: Text replacement - "sub-question" to "subquestion"

2018-09-28T10:40:12Z

Text replacement - "sub-question" to "subquestion"

Han: /* Optimize LimeSurvey for Long Surveys (and better performance and maintenance in general) */

2013-06-17T13:46:05Z

Optimize LimeSurvey for Long Surveys (and better performance and maintenance in general)

← Older revision		Revision as of 15:46, 17 June 2013
Line 231:		Line 231:
	----		----

	==Optimize LimeSurvey for Long Surveys ~~(and better performance and maintenance in general)~~==		==Optimize LimeSurvey for Long Surveys==

	Although LimeSurvey is excellent for short and mid-length surveys, it is not optimized for surveys with hundreds or thousands of questions - such as those used by epidemiologists or in clinical trials. This project would tackle each of those main limitations. Those sub-tasks, and the development strategy include:		Although LimeSurvey is excellent for short and mid-length surveys, it is not optimized for surveys with hundreds or thousands of questions - such as those used by epidemiologists or in clinical trials. This project would tackle each of those main limitations. Those sub-tasks, and the development strategy include:

C schmitz: Text replace - "ç" to "ç"

2013-06-09T19:28:36Z

Text replace - "ç" to "ç"

← Older revision		Revision as of 21:28, 9 June 2013
Line 102:		Line 102:
	c_schmitz		c_schmitz

	Diogo ~~Gonçalves~~ (dionet)		Diogo Gonçalves (dionet)

	'''Want to know more'''		'''Want to know more'''
Line 133:		Line 133:
	Jason Cleeland (jcleeland)		Jason Cleeland (jcleeland)

	Diogo ~~Gonçalves~~ (dionet)		Diogo Gonçalves (dionet)

	----		----
Line 158:		Line 158:
	Jason Cleeland (jcleeland)		Jason Cleeland (jcleeland)

	Diogo ~~Gonçalves~~ (dionet)		Diogo Gonçalves (dionet)

	----		----

Choffman at 21:47, 13 June 2012

2012-06-13T21:47:43Z

← Older revision		Revision as of 23:47, 13 June 2012
Line 34:		Line 34:
	----		----

	==Implement a fully featured ~~XMP~~-RPC API + API tests + unit test==		==Implement a fully featured XML-RPC API + API tests + unit test==

	LimeSurvey urgently needs an API so all administration functions (and later even survey-taking functions) can be accessed without using the GUI. In addition you will be implementing an according unit test framework and implement unit & API tests across the whole application so we can make sure at any point in the development process that the application is functioning as it should.		LimeSurvey urgently needs an API so all administration functions (and later even survey-taking functions) can be accessed without using the GUI. In addition you will be implementing an according unit test framework and implement unit & API tests across the whole application so we can make sure at any point in the development process that the application is functioning as it should.

TMSWhite at 13:04, 29 March 2012

2012-03-29T13:04:47Z

Show changes

Dionet at 21:59, 6 March 2012

2012-03-06T21:59:31Z

← Older revision		Revision as of 23:59, 6 March 2012
Line 75:		Line 75:
	==Implement a plugin framework for authentication/languages/ import/export modules==		==Implement a plugin framework for authentication/languages/ import/export modules==

	The idea is to design and implement a modular "framework" for LimeSurvey as well as convert the existing ~~funcitonaly~~ to according modules. The framework will define the API each plugin type must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, etc.).		The idea is to design and implement a modular "framework" for LimeSurvey as well as convert the existing functionality to according modules. The framework will define the API each plugin type must (or may) implement and propose basic methods that can be used by plugins (for instance how to store the plugins parameters in DB, etc.).

	The plugin framework should be in parts similar to the framework used by Joomla (XML description files in the plugin packages)		The plugin framework should be in parts similar to the framework used by Joomla (XML description files in the plugin packages)
Line 101:		Line 101:

	c_schmitz		c_schmitz

			Diogo Gonçalves (dionet)

	'''Want to know more'''		'''Want to know more'''

TMSWhite at 21:45, 6 March 2012

2012-03-06T21:45:57Z

Show changes

Jcleeland at 22:51, 4 March 2012

2012-03-04T22:51:54Z

← Older revision		Revision as of 00:51, 5 March 2012
Line 51:		Line 51:
	----		----

	==~~Develop~~ improved 'bulk' question handling UI ~~(and other UI enhancements)==~~		==User Interface Improvements and Backend Tidy Ups==

			Help improve LimeSurvey's usability and flexibility through a range of small tasks such as:
			* develop improved 'bulk' question handling UI
			* Tidy up input values on public surveys by moving required values from html inputs to javascript variables

	The idea is to provide ways of updating and modifying multiple questions, or multiple groups in one go. Often in a survey a user will need to make parallel changes to 5 or 6 questions all at once across a range of different groups. Being able to select various elements of questions, and then select a range of questions to edit would dramatically improve LimeSurvey's usability from the administrators perspective.		The idea is to provide ways of updating and modifying multiple questions, or multiple groups in one go. Often in a survey a user will need to make parallel changes to 5 or 6 questions all at once across a range of different groups. Being able to select various elements of questions, and then select a range of questions to edit would dramatically improve LimeSurvey's usability from the administrators perspective.

Admin at 13:47, 2 March 2012

2012-03-02T13:47:24Z

← Older revision		Revision as of 15:47, 2 March 2012
Line 23:		Line 23:
	*Extensive knowledge of PHP & Yii framework		*Extensive knowledge of PHP & Yii framework
	*Very good kownledge of LimeSurvey inner workings		*Very good kownledge of LimeSurvey inner workings
	*Very good OOP ~~knowledg~~		*Very good OOP knowledge

	'''Difficulty'''		'''Difficulty'''

← Older revision		Revision as of 12:40, 28 September 2018
Line 172:		Line 172:
	***Utilize auto-complete, ideally letting users see and choose among the availalbe function syntaxes (e.g. when a function can take several paameters).		***Utilize auto-complete, ideally letting users see and choose among the availalbe function syntaxes (e.g. when a function can take several paameters).
	***Auto-completion of variable names should show the question and question type to make it easier for users to pick the correct variable.		***Auto-completion of variable names should show the question and question type to make it easier for users to pick the correct variable.
	#Support ~~sub-question~~-level Relevance		#Support subquestion-level Relevance
	**Background: EM already supports user-entered relevance equations at the group and question levels. It also generates ~~sub-question~~-level relevance for features like array_filter. Users would like to be able ot add additional relevance criteria at the ~~sub-question~~ level.		**Background: EM already supports user-entered relevance equations at the group and question levels. It also generates subquestion-level relevance for features like array_filter. Users would like to be able ot add additional relevance criteria at the subquestion level.
	**Strategy:		**Strategy:
	***Add a relevance column to the display of ~~sub-questions~~, and ensure entered relevance is saved the to database (the data model is already OK)		***Add a relevance column to the display of subquestions, and ensure entered relevance is saved the to database (the data model is already OK)
	***Refactor createFieldMap() (or its successor) to read ~~sub-question~~-level relevance into the run-time data structures so that passed to EM		***Refactor createFieldMap() (or its successor) to read subquestion-level relevance into the run-time data structures so that passed to EM
	***Enhance EM's ~~sub-question~~-level data structures to hold ~~sub-question~~-level releavance		***Enhance EM's subquestion-level data structures to hold subquestion-level releavance
	***Update EM's _ValidateQuestion() and JavaScript generation functions to AND any manually-entered ~~sub-question~~-level relevance equations with that auto-generated for array_filter and array_filter_exclude		***Update EM's _ValidateQuestion() and JavaScript generation functions to AND any manually-entered subquestion-level relevance equations with that auto-generated for array_filter and array_filter_exclude
	*Update ShowSurveyLogicFile() to show ~~sub-question~~-level relevance equations *Rigorously unit and regresssion test these changes.		*Update ShowSurveyLogicFile() to show subquestion-level relevance equations *Rigorously unit and regresssion test these changes.
	#Add Sub-question-level Validation		#Add Sub-question-level Validation
	**Background: The question-level validation supports regular-expression-based validation of each ~~sub-question~~. Users would like to have ~~sub-question~~-level validation to implement things like a question for collecting user contact information, where there are different validation criteria for address parts (e.g. city, state, postal code) and phone numbers.		**Background: The question-level validation supports regular-expression-based validation of each subquestion. Users would like to have subquestion-level validation to implement things like a question for collecting user contact information, where there are different validation criteria for address parts (e.g. city, state, postal code) and phone numbers.
	**Strategy: Similar to ~~sub-question~~-level relevance		**Strategy: Similar to subquestion-level relevance
	***Add data entry fields for regular expression validation at the ~~sub-question~~ level, and ensure saved to database (which already has a preg field at the ~~sub-question~~ level)		***Add data entry fields for regular expression validation at the subquestion level, and ensure saved to database (which already has a preg field at the subquestion level)
	***Ensure EM gets access to the new preg values (via upgrade to createFieldMap)		***Ensure EM gets access to the new preg values (via upgrade to createFieldMap)
	***Upgrade EM _ValidateQuesation() and function for generation of validation equations to include these new critiera. EM already supports validation at the ~~sub-question~~ level (and changes the CSS style to show fields that fail this validation)		***Upgrade EM _ValidateQuesation() and function for generation of validation equations to include these new critiera. EM already supports validation at the subquestion level (and changes the CSS style to show fields that fail this validation)
	***Upgrade ShowSurveyLogicFile() to show ~~sub-question~~-level validation rules		***Upgrade ShowSurveyLogicFile() to show subquestion-level validation rules
	***Rigorously unit and regresssion test these changes.		***Rigorously unit and regresssion test these changes.
	#Add Sub-question-level mandatory criteria		#Add Sub-question-level mandatory criteria
	**Background: Many users have asked, via the forums, for ways to make parts of a multi-part questions mandatory, but make other parts optional. LimeSurvey already provides many options, such as minimum and maxium numbers of answers; but users have asked for more fine-grained control, and currently can only achieve that via custom JavaScript.		**Background: Many users have asked, via the forums, for ways to make parts of a multi-part questions mandatory, but make other parts optional. LimeSurvey already provides many options, such as minimum and maxium numbers of answers; but users have asked for more fine-grained control, and currently can only achieve that via custom JavaScript.
	**Strategy: Similar to ~~sub-question~~-level relevance		**Strategy: Similar to subquestion-level relevance
	***Add checkbox to indicate mandatory status at the ~~sub-question~~ level		***Add checkbox to indicate mandatory status at the subquestion level
	#Add native support for input-masks at the question and ~~sub-question~~ level		#Add native support for input-masks at the question and subquestion level
	**Background: One of the commonly used work-arounds deals with input masks, such as the jQuery meimomask plugin.		**Background: One of the commonly used work-arounds deals with input masks, such as the jQuery meimomask plugin.
	**Strategy:		**Strategy:
	***Add mask attribute at question and ~~sub-question~~ level		***Add mask attribute at question and subquestion level
	***Have EM generate needed JavaScript code to create and manage those masks		***Have EM generate needed JavaScript code to create and manage those masks
	#Add EM reporting functions (tables)		#Add EM reporting functions (tables)
Line 203:		Line 203:
	***Implement showTheseResponses(attributeList,attributeTitleList,questionList) function. questionList = list of question identifiers; attributeList = pipe-delimited list of attributes (like question#, title, text, type - so you can decide what to show); attributeTitleList = pipe-delimited list of table headers, so can internationalize the report.		***Implement showTheseResponses(attributeList,attributeTitleList,questionList) function. questionList = list of question identifiers; attributeList = pipe-delimited list of attributes (like question#, title, text, type - so you can decide what to show); attributeTitleList = pipe-delimited list of table headers, so can internationalize the report.
	#Add better EM support for operations on array type questions		#Add better EM support for operations on array type questions
	**Background: Many of the EM validation rules are effectively statements like count the number of empty ~~sub-questions~~, or sum the values of the ~~sub-questions~~. EM generates these functions itself, so there is no burden on the user, even if there ar dozens of sub-quetions. However, manual editing of these questions is cumbersom. Users could benefit from special variables to access all of the elements of a question so that they could write functions like (sum(this) == 10)) and have it be expanded to (sum(q1_1, q1_2, ..., q1_N) == 10). Note, there is already a "this" variable, but it does not apply to ~~sub-questions~~.		**Background: Many of the EM validation rules are effectively statements like count the number of empty subquestions, or sum the values of the subquestions. EM generates these functions itself, so there is no burden on the user, even if there ar dozens of sub-quetions. However, manual editing of these questions is cumbersom. Users could benefit from special variables to access all of the elements of a question so that they could write functions like (sum(this) == 10)) and have it be expanded to (sum(q1_1, q1_2, ..., q1_N) == 10). Note, there is already a "this" variable, but it does not apply to subquestions.
	**Strategy:		**Strategy:
	***Extend EM so that "this" variable gets expanded into a comma separate list of ~~sub-question~~ references if there are ~~sub-questions~~. Have this expansion carry the suffix, so this.valueNAOK would become q_1.valueNAOK, q_2.valueNAOK, ..., q_N.valueNAOK.		***Extend EM so that "this" variable gets expanded into a comma separate list of subquestion references if there are subquestions. Have this expansion carry the suffix, so this.valueNAOK would become q_1.valueNAOK, q_2.valueNAOK, ..., q_N.valueNAOK.
	***This macro expansion should occur in group.php (e.g. in the process of generating JavaScript), rather than having this variable be resolved at run-time within JavaScript.		***This macro expansion should occur in group.php (e.g. in the process of generating JavaScript), rather than having this variable be resolved at run-time within JavaScript.
	**Provide similar array-expansion macros for all variables (not just "this") - such as qcode_vars.. This would also functions like sum(qcode_vars.NAOK), count(qcode_vars.NAOK), implode(' ', qcode_vars.valueNAOK)		**Provide similar array-expansion macros for all variables (not just "this") - such as qcode_vars.. This would also functions like sum(qcode_vars.NAOK), count(qcode_vars.NAOK), implode(' ', qcode_vars.valueNAOK)
Line 214:		Line 214:
	**Strategy:		**Strategy:
	***Create EM-compatible PHP and JavaScript functions to access CTS-2 compliant EVS systems		***Create EM-compatible PHP and JavaScript functions to access CTS-2 compliant EVS systems
	***Should include question and ~~sub-question~~-level validation rules to validate the final entry. Currently, thre are em_validation_q and em_validation_sq advanced quation attributes for validating questions and ~~sub-questions~~ based upon calls to external functions. It may be desirable to support custom ~~sub-question~~-level validation to validate each ~~sub-question~~ against different value sets. If so, can follow the model of adding ~~sub-question~~-level validation and relevance. Alternatively, may be desirable to add ~~sub-question~~-level advanced question options (if LimeSurvey community feels that there may be enough such extensions that such customization should be stored in a general attribute table rather than making the questions table wider).		***Should include question and subquestion-level validation rules to validate the final entry. Currently, thre are em_validation_q and em_validation_sq advanced quation attributes for validating questions and subquestions based upon calls to external functions. It may be desirable to support custom subquestion-level validation to validate each subquestion against different value sets. If so, can follow the model of adding subquestion-level validation and relevance. Alternatively, may be desirable to add subquestion-level advanced question options (if LimeSurvey community feels that there may be enough such extensions that such customization should be stored in a general attribute table rather than making the questions table wider).
	***Should also include ability to do incremetal searches into the value sets		***Should also include ability to do incremetal searches into the value sets

Line 264:		Line 264:
	**Background: qanda.php loads the content to create the questions and answers. It used to do this by separate database queries per question.		**Background: qanda.php loads the content to create the questions and answers. It used to do this by separate database queries per question.
	**Strategy		**Strategy
	***Refactor qanda.php to remove queries (like for "other", or ~~sub-question~~ text) - have it get that information from EM		***Refactor qanda.php to remove queries (like for "other", or subquestion text) - have it get that information from EM
	***Refactor LS so that language switching does not require a re-load of the core logic, but just the new language content (and that it gets this from EM)		***Refactor LS so that language switching does not require a re-load of the core logic, but just the new language content (and that it gets this from EM)
	***Refactor replacements.php and EM		***Refactor replacements.php and EM