View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
05684 | Bug reports | Other | public | 2012-01-24 02:42 | 2012-01-30 18:40 |
Reporter | tpartner | Assigned To | TMSWhite | ||
Priority | normal | Severity | minor | ||
Status | closed | Resolution | fixed | ||
Product Version | 1.92RC2 | ||||
Target Version | 1.92RC3 | Fixed in Version | 1.92RC3 | ||
Summary | 05684: EM overrides code in template.js | ||||
Description | Code placed in template.js that is supposed to hide a question with sub-questions at all times can now overridden by EM based upon whether the sub-questions are relevant. EM calls question.show()/hide() after template.js has loaded. For example, if you have the following code in template.js that is intended to hide a multiple-options question, it does not work if EM applies "relevancy" to the sub-questions. $('#question11').hide(); Perhaps, to be backwards compatible, template.js should take precedence over all auto-generated JavaScript (as should template.css). | ||||
Tags | No tags attached. | ||||
Attached Files | |||||
Bug heat | 6 | ||||
Complete LimeSurvey version number (& build) | 12464 | ||||
I will donate to the project if issue is resolved | No | ||||
Browser | FF & IE | ||||
Database type & version | MySQL 5.1.41 | ||||
Server OS (if known) | Win | ||||
Webserver software & version (if known) | Apache/2.2.14 | ||||
PHP Version | 5.3.1 | ||||
Please provide some specific examples where template.js tries to hide a question so I can assess whether it does things that EM not. EM's relevancy supports cascading conditions perfectly, including NULLing values in the database and restoring default values when needed. It is unlikely that custom-build template.js will cope with all such conditions. So, although backwards compatability should be a goal, perhaps we should have a survey-specific parameter that lets people choose whether EM or template.js will take precedence, so they can compare/contrast without too much difficulty. |
|
In my opinion, since LS is template-based, the template.js file should always take precedence. Attached are a template and survey. In group 2 of the survey there is a multiple-options question that is filtered by the multiple-options in Group 1. This question is used to control the display of ranking options and supposed to be hidden by code in template.js. In 1.92 the multiple-options is forced to be shown by EM. Here's a link to the survey on 1.91 - http://www.partnersinc.biz/surveys//index.php?sid=64913 |
|
Since it looks like template.js is always optional (is that true), then there is no harm in having it over-ride EM. People can easily change their configuration. Since you are finding that it works if you put template.js in endpage.pstpl file, is that an OK solution, or do we need to try to find a way to support having it in startpage.pstpl? |
|
To be backwards compatible, I think we need to support it in startpage.pstpl. There may be many custom templates out there using similar code. |
|
tpartner- Can you provide another example too? It is supposed to be possible to array_filter ranking questions (but it doesn't work). I'm inclined to find a way to get EM to support that rather than require custom JavaScript for that particular functionality. Can you help me understand the desired call flow for JQuery? Right now, EM is called from checkconditions(), which is called via onchange event from every question. If you really wanted to call template.js stuff after EM finished, what's a good way to do that? Simply calling the $(document).ready(function()) seems like it could give unpredictable results depending upon where it occurs within the queue of functions to run. /Tom |
|
Tom, I'm afraid I don't see the need for another example. The point is not whether or not we can get a filtered ranking question working but whether the user will have final control of elements to be displayed using the template files (either template.css or template.js). In the last few releases there has been a tendency to add more and more inline JavaScript which gets executed after template.js and survey_runtime.js, reducing their effectiveness. As for EM being called from checkconditions() when an onchange is detected, it also must be fired on page load becuase it is showing questions which have been hidden in a previous $(document).ready(function(). |
|
Tony- EM used to be called on page load. That was fixed in revision 12117 (after release of LS 1.92 RC2). I'm still not clear on the best way to ensure that template.js gets called last. What do you recommend? /Tom |
|
Ah, checkconditions() is being called by survey_runtime.js which is loaded after template.js. A solution to that may be to load it before template.js. A related problem though: If I load template.js after survey_runtime.js, the code in template.js works as expected (the multi-opt is hidden) but... When a question (like the ranking in this case) is changed, checkconditions() is fired which shows the question multi-opt again. This occurs even if there are no conditions applied to the multi-opt. checkconditions() is being called from rankthis_xx(). |
|
we shouldn't need to call checkconditions from survey_runtime.js - EM should make sure they are all OK before the page loads. Hmm, not calling checkconditions after rankthis_xxx() could be a problem - what if there are conditions based upon its values? could there be a way to call template.js at the end of checkconditions()? If so, what is the best way to do that? |
|
Well, removing that call from survey_runtime.js would certainly be a step forward. You are correct that we need to call checkconditions() in rankthis_xxx() to handle any possible conditions on the ranking question. I don't see that calling template.js at the end of checkconditions() is an option. It would typically be full of stuff for page load and other pages/groups. Is there anyway for EM to detect if a question has display:none applied to it and then leave it alone if no condition or relevance is triggered to show the whole question? |
|
I checked, and removing the call to checkconditions() from survey_runtime.js is fine (other than the initial tab ordering might not be quite desirable). The sample you gave used array_filter. EM now controls that, so it has to check whether the question is relevant, and if so, then processes the sub-question-level validation (array_filter), and shows the question. So, checking display:none in that case wouldn't work. However, we could use some external variables to force a question to be invisible. For example, right now, if a question is relevant, we have code like this: if(1) { How about having template.js create an attribute like $('#question243').attr('hideme','1') and then EM could modify that query to look like if(1) { |
|
fixed in revision 12190 |
|
turns out removing call to checkconditions from survey_runtime.js was overkill - broke some things. Putting it back in, your tests still work. |
|
1.92RC3 released |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2012-01-24 02:42 | tpartner | New Issue | |
2012-01-24 02:42 | tpartner | Status | new => assigned |
2012-01-24 02:42 | tpartner | Assigned To | => TMSWhite |
2012-01-24 04:33 | TMSWhite | Note Added: 16933 | |
2012-01-24 12:54 | tpartner | File Added: ranking_filter_demo.zip | |
2012-01-24 12:55 | tpartner | File Added: limesurvey_survey_broken_ranking_filter.lss | |
2012-01-24 13:02 | tpartner | Note Added: 16936 | |
2012-01-24 14:56 | TMSWhite | Note Added: 16939 | |
2012-01-24 15:02 | tpartner | Note Added: 16940 | |
2012-01-24 16:09 | TMSWhite | Note Added: 16941 | |
2012-01-24 17:24 | tpartner | Note Added: 16944 | |
2012-01-24 17:47 | TMSWhite | Note Added: 16945 | |
2012-01-24 18:58 | tpartner | Note Added: 16946 | |
2012-01-24 19:14 | TMSWhite | Note Added: 16947 | |
2012-01-24 19:31 | tpartner | Note Added: 16948 | |
2012-01-24 21:32 | TMSWhite | Note Added: 16964 | |
2012-01-24 23:07 | TMSWhite | Note Added: 16966 | |
2012-01-24 23:07 | TMSWhite | Status | assigned => resolved |
2012-01-24 23:07 | TMSWhite | Fixed in Version | => 1.92RC3 |
2012-01-24 23:07 | TMSWhite | Resolution | open => fixed |
2012-01-26 19:37 | TMSWhite | Note Added: 16995 | |
2012-01-30 18:40 | c_schmitz | Note Added: 17062 | |
2012-01-30 18:40 | c_schmitz | Status | resolved => closed |