This topic is a place for LimeSurvey community members to comment on the Google Summer of Code proposal to port LimeSurvey to CodeIgniter.

The proposal is available here:

http://docs.limesurvey.org/Porting+LimeSurvey+to+CodeIgniter

I found CodeIgniter to be cumbersome...

LimeSurvey already appears to have a lot of code bloat on its own. Adding one more layer to that seems like a bad idea.

Maybe the current code could be optimized and refactored instead?

CI will give us the needed frame to refactor the current code. It is (contrary to CakePHP) very fast and absolutely NOT bloated.

I'd like to work with the team to integrate ExpressionManager into the CodeIgniter branch.

It would provide at least the following functions:
(1) Do all replacements within curly braces (e.g. {INSERTANS:xxxx}, {TOKEN:xxxx}, and all templatereplace() values), supporting recursive substitution and complex conditional formatting.
(2) Support complex conditional calculation, logic, and formatting -- providing a back-end replacement for both Conditions and Assessments
(3) Enable an "Equation" question type
(4) Enable "Relevance", which support arbitrarily complex (and chained) conditional logic to determine which questions or groups are displayed without requiring JavaScript.

Now that it is mostly done (e.g. all of the server-side processing and calculations work, and I'm starting to work on the client-side JavaScript equivalents), I'd like to get it integrated into the CI branch so that the CI release doesn't need to port the legacy approach to dealing with Conditions and Assessments.

Using ExpresionManger, the workflow for navigation is this:
(1) Collect next set of potentially relevant questions (e.g. next group)
(2) Evaluate Relevance equation for each question to determine which questions should be asked/displayed
(3) If no questions are relevant, then skip that group and repeat with step #1. If there are no more potentially relevant questions, then the survey is done.
(4) If a Group has no relevant questions, but does have relevant Equations, evaluate them and store their result in the database before looping to step #1

Once a set of questions to be displayed is identified:
(1) Compose the page based upon the template, inserting the appropriate question and answer types
(2) Do recursive substitution of variables within curly braces (e.g. answers, tokens, equations).

This should simplify the data model and improve performance too. The Conditions and Assessment tables would no longer be needed.
However, since ExpressionManager can support significantly more complex conditions and assessments, we may need to have LimeUser and LimeExpert modes, where LimeUser mode is the GUI that everyone is familiar with, and LimeExpertMode provides access to more complex equations without requiring a GUI (at least until we can build a nice one for it).

If you can point me in the right direction, I can start working on a patch:
(1) Where should I put the core ExpressionManager code (currently in /classes/eval/*)
(2) Which controllers deal with processing templates and doing the replacements (e.g. templatereplace(), insertAnsReplace(), tokenReplace(), dTexts::run())
(3) Which controllers deal with navigation, conditions, and assessments?

I can provide working examples of this functionality in the limesurvey_dev_tms branch (or hosted on my website) if that would help start this dialog.

Hello, thank you for your interest in the CodeIgniter branch.

To answer your questions:

(1) It looks like you can easily put those files inside of application/libraries/ without modification. You would then call those classes as a CI library. The user guide explains this very well.

(2) You can find the functions you mentioned at /application/helpers/common_helper.php; dTexts is available at /application/helpers/dTexts/ folders.

(3) I’m currently porting conditions controller and it will be finished in the next week. Assessments controller is at /application/controllers/admin/assessments.php. I’m not sure what you meant by "navigation".

Please note that I’m referring to back-end controllers. Front-end controllers will be started in the following weeks.

If you have any other question, feel free to ask.

Thanks, I'm just starting to dig into this.

Question, which subset of the CodeIgniter framework is required, desired, and/or to be avoided in the _ci port? Of those that are required or desired, what is the prioritization of converting existing code over to using the CI approach?

CI Class	How Used? (required, desired, optional, avoid)	Priority
Benchmarking Class	??	??
Calendar Class	??	??
Cart Class	??	??
Config Class	??	??
Database Class	??	??
Email Class	??	??
Encryption Class	??	??
File Uploading Class	??	??
Form Validation Class	??	??
FTP Class	??	??
HTML Table Class	??	??
Image Manipulation Class	??	??
Input Class	??	??
Javascript Class	??	??
Loader Class	??	??
Language Class	??	??
Output Class	??	??
Pagination Class	??	??
Security Class	??	??
Session Class	??	??
Trackback Class	??	??
Template Parser Class	??	??
Typography Class	??	??
Unit Testing Class	??	??
URI Class	??	??
User Agent Class	??	??
XML-RPC Class	??	??
Zip Encoding Class	??	??

Hello TMSWhite,

I am not sure if i understand your question correctly, but classes you have mentioned are inbuilt classes that come with CI package. You don't need to modify any of these classes(until,ofcourse, the situation demands so!). AFAIK, we've not modified any of these classes, so most probably you will find it ready to use for EM. You can see CI user guide to see how they are used and there purpose.

Correct me if i didn't understand your question correctly or you still have any doubts.

Hi

CI Classes were used where applicable. In may cases they had shortcomings so magiclko and dionet used the 'old' ones from LimeSurvey. (for example the Email class). I suggest not to modify the original CI classes unless you want to contribue back to the CI project itself. Not modifying the CI class will guarantee us an easy update to later CI versions.

Thanks. I wasn't suggesting modifying the CI classes. Rather, are there some classes that should not be used (like Email, since it has shortcomings compared to the 1.91 email system); and are there classes that should absolutely be used (e.g. replace all database calls so that they use CI db class)

I think the best answer is:

Use CI whereever you can except if hit any shortcoming.

Only the Session class is really flawed and you rather should use for survey taking the standard $_SESSION object instead (because the session class can only store a limited amount of information).