Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: {INSERTANS:{SGQ}} in 1.92rc1

{INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71626

  • fransmarcelissen
  • fransmarcelissen's Avatar
  • OFFLINE
  • Expert Lime
  • Posts: 128
  • Thank you received: 18
  • Karma: 5
In 1.91 I often use the construct {INSERTANS:{SGQ}} as a reference to the value of the current question. This appears do not work in 1.92rc1. It appears that {INSERTANS:{SGQ}} is not recognized, although {INSERTANS:777X777X777} and {SGQ} are both accepted. Is this a bug, or are I missing something?
BTW: is there in EM a way to reference to the current question?
EM is a very important development. What I am still desperately missing is the assignment ({XXXX}=8888).
And when will rc2 and the final release be ready?
Last Edit: 2 years 6 months ago by fransmarcelissen.
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71627

  • TMSWhite
  • TMSWhite's Avatar
  • OFFLINE
  • LimeSurvey Team
  • Posts: 759
  • Thank you received: 82
  • Karma: 36
fransmarcelissen-

{INSERTANS:{SGQ}} will not work in EM. However, if you are trying to get the value, you can use the syntax described here to access the current value and many question attributes.

Someone else also asked, today, about a "this" variable to access the current question. I'm looking into that.

Please give me an example of assignment. EM supports it, but I've turned it off because I didn't see any obvious cases where assignment was safe. How did you want to use it?

RC2 is ready - just needs to be packaged and released - so in the next day or so.
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71635

  • fransmarcelissen
  • fransmarcelissen's Avatar
  • OFFLINE
  • Expert Lime
  • Posts: 128
  • Thank you received: 18
  • Karma: 5
Thanks Tom,
I use this constuction (in 1.91) as a way of setting default values (in javascript):
$(document).ready(function()
{if ('{INSERTANS:{SGQ}}'==''){ $('#answer'+'{SGQ}').val('Some value');}}

The nice thing here is that this can be used in each question, without mentioning explicitly the name of this question.
I hoped that my questionnaire would be upwards compatible from 1.91 to 1.92, but this does not work.
At this moment there is (I think) no way of doing this in EM, because an assignment and a "this" variable would be needed for that.
Above is the first example of the use of assignment. Another example this the following. I have a psychological questionnaire (the workability index) where the calculation of the score takes about 50 lines of code.
At this moment I do this in javascript, i.e. (this is not limesurvey code, but I hope I can use 1.92 from now on;v1 v2,... are input parameters, or questions)
.
.

var score=0;
score=v2;
switch (v1)
{
case 1: score=score+v3a*0.5+v3b*1.5;break;
case 2: score=score+v3a*1.5+v3b*0.5;break;
case 3: score=score+v3a+v3b;break;
}
var aandoeningen=[v4_1,v4_2,v4_3,v4_4,v4_5,v4_6,v4_7,v4_8,v4_9,v4_10,v4_11,v4_12,v4_13,v4_14]
var aantalklachten = 0;
for (var x = 0; x <aandoeningen.length; x++)
if (aandoeningen[x]==2) aantalklachten += 1;
switch (aantalklachten)
{
case 0: score +=7; break;
case 1: score +=5; break;
case 2: score +=3; break;
case 3: score +=3; break;
case 4: score +=1; break;
default: score +=1;break;
}
(etc)
This would be very difficult without assignment to a local (or temporary, or scratch) variable.
A third example of assignment: often psychological tests results in more than one score (let's say: verbal intelligence, nonverbal intelligence and general intelligence).
Each score can be calculated within the equation question type. That means, however, spreading the calculation over three equation questions. I would rather say: VI=....;VN=...;VT=....
That makes debugging and maintaining much more simple.
Last Edit: 2 years 6 months ago by fransmarcelissen.
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71639

  • floccs
  • floccs's Avatar
  • OFFLINE
  • Senior Lime
  • Posts: 47
  • Thank you received: 5
  • Karma: 2
Hi Tom,

I reply here since I think it is a more appropriate space since it is not strictly related to the release of the 1.92 RC1 version.

What fransmarcelissen has said is exactly what I intended to say in my earlier post.
In my case I have done a question which add the ability to track respondents answers across multiple surveys without the need of tokens.
This question has some dropdown list. The selected values are then concatenated and encrypted with sha1 (with javascript code) for privacy reasons. The value is then stored in the text field of the question with
$('#answer'+'{SGQ}').val(sha1value);

In reality I didn't know the possibility to use {SGQ} and I always added manually the SGQ of the question, so I thought that what I was asking was a new feature. But with my 'discovery' of the {SGQ} I think that EM should give the same features of 1.91+ releases giving at least the same {SGQ} replacer or 'this' selector (which has to work in order to make true this.SGQA = {SGQ})

Stefano
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71748

  • TMSWhite
  • TMSWhite's Avatar
  • OFFLINE
  • LimeSurvey Team
  • Posts: 759
  • Thank you received: 82
  • Karma: 36
flocs -

We can certainly add {SGA}. Supporting nested curly braces would require some changes to EM that I can explore, but not promise. Right now, if it tries to parse {INSERTANS:{SGQ}}, it yields {INSERTANS:{SGQ}.

Your idea is interesting and potentially powerful, so I will look into it. Most of my programming work in the past involved code-generating-code, so I'd like to support that here too, if possible.

/Tom
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71754

  • TMSWhite
  • TMSWhite's Avatar
  • OFFLINE
  • LimeSurvey Team
  • Posts: 759
  • Thank you received: 82
  • Karma: 36
fransmarcelissen wrote:
This would be very difficult without assignment to a local (or temporary, or scratch) variable.

A third example of assignment: often psychological tests results in more than one score (let's say: verbal intelligence, nonverbal intelligence and general intelligence).
Each score can be calculated within the equation question type. That means, however, spreading the calculation over three equation questions. I would rather say: VI=....;VN=...;VT=....
That makes debugging and maintaining much more simple.

fransmarcelissen-

Although I've designed EM to support assignments of variables, I recommend against it based upon my experience. I also disagree with you about maintenance. I've found it quite easy to maintain large surveys that have numerous calculations (equation <a href='www.docs.limesurvey.org/tiki-index.php?p...tions+for+LimeSurvey'><a href='www.docs.limesurvey.org/tiki-index.php?p...tions+for+LimeSurvey'>question types</a></a>) within them.

The previous survey tool I developed was geared towards psychiatric epidemiology. Our surveys averaged 2000+ questions long. We even encoded the entire SCID-I and SCID-II (psychiatric diagnostic instruments), and they were actually among the shorter instruments in our collection despite being over a 1000 questions each.

For the SCID-II (personality disorders), our epidemiologist was worried about length and response fatigue, so she asked that we ask the minimum number of questions needed to rule in or rule out a verifiable diagnosis. So we asked the subject all of the core questions, then sent the survey electronically to a psychologist. The tool then directed him to ask follow-up questions about each alleged symptom, and the tool ensured that he only had to ask the minimum number of questions needed to rule in or rule out the diagnosis.

Of course, we also computed all of the SCID-II diagnoses and sub-scale scores - with one value per equation so that our database stored the individual diagnoses in separate variables.

I implemented the SCID-II using a set of temporary variables so that I could increment or decrement the symptom counters per diagnostic category. This initially seemed fine. However, if the psychologist had to back up and change anything, the counters would get messed up.

So, we switched to having temporary variables that computed the entire symptom score between each set of questions. True, we repeated the calculation many times, but it was an easy cut and paste (we only had to change the name of the variable), and it ensured accuracy of the results even if we backtracked, started/resumed, etc.

Personally, I'd recommend that strategy.

For example, say your score of verbal intelligence has 10 questions named v1-v10, your equation would be either this (if you want to only compute the score if all questions are answered:
sum(v1,v2,v3,...,v10)

or this (if you're OK with a running total):
sum(v1.NAOK,v2.NAOK,...,v10.NAOK)

I find this makes it easier to read, especially if you're working with researchers or clients who want to validate the equations. Few of them want to validate JavaScript code for accuracy.

/Tom
Last Edit: 2 years 6 months ago by TMSWhite.
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71758

  • TMSWhite
  • TMSWhite's Avatar
  • OFFLINE
  • LimeSurvey Team
  • Posts: 759
  • Thank you received: 82
  • Karma: 36
flocs-

Well, I tried, but {INSERTANS:{SGQ}} isn't going to work well. Although I can get that to work, it would break any regular expressions that use {min,max} repeats of a pattern. {SGQ} does work, by the way.

However, it is easy to add new replacement values now, so let's figure out what you need. {INSERTANS:{SGQ}} is really just an attempt to get the display value for the question (what I'd call qcode.shown, or this.shown). You might also want the coded value, or the assessment value, which I'd call qcode.code, and qcode.value, respectively.

As you can see from here, under New Variable Attributes, there are many attributes available. We already have fieldnames like {QUESTION_CODE, QUESTION_TEXT, etc. What do you think about adding to that list rather than creating a "this" variable?

Also, your first example seems to be trying to set default values. Support for defaults is more robust in 1.92, and could be pretty easily extended further.

/Tom
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71759

  • fransmarcelissen
  • fransmarcelissen's Avatar
  • OFFLINE
  • Expert Lime
  • Posts: 128
  • Thank you received: 18
  • Karma: 5
Hi fellows,
Tom: I do not fully understand what you are saying. If you intend to say that assignments can be considererd as "bad programming" and should be avoided, I agree with that. But there are occasions where missing them results in much clumsy programming.
I still do not understand how I should calculate scores that involve many sequential steps, like the example above. I think I need assignments to temporary variables for that.
If there are alternatives for {INSERTANS:{SGQ}}, thats fine. It "breaks" the principle of upwards compatibility with 1.91, however.
I would say the solution of "this" is more simple than adding new fieldnames, but if there are reasons to do it diffently, I will not argue.
I agree that my first example is a "trick" to set default values. How 1.92 does support defaults?
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71843

  • floccs
  • floccs's Avatar
  • OFFLINE
  • Senior Lime
  • Posts: 47
  • Thank you received: 5
  • Karma: 2
Hi Tom,

What I'm really looking for is a fast way to access question attribute of the question I'm writing in without the need of specifying the Qcode or SGQ.

Suppose I have a brief text question that has question code Q1 and SGQ 1X1X1,
for some reason I want to write a value in the answer field using javascript (embedded within the Q1 question text).

What I've done until now (1.91+) is
$("#answer1X1X1").val(computedValue);
//with the need of changing SGQ every time I reimport the question

What I could have done until now (1.91+) is
$("#answer{SGQ}").val(computedValue);
//without the need of changing anything

What I could do with EM (1.92) is
$("#answer{Q1.SGQA}").val(computedValue);
//with the need of changing Q1 every time I reimport the question and/or change question code

What I wish I could do with EM is
$("#answer{this.SGQA}").val(computedValue);
//without the need of changing anything

I hope that I've explained well my request

Stefano
The administrator has disabled public write access.

Re: {INSERTANS:{SGQ}} in 1.92rc1 2 years 6 months ago #71867

  • TMSWhite
  • TMSWhite's Avatar
  • OFFLINE
  • LimeSurvey Team
  • Posts: 759
  • Thank you received: 82
  • Karma: 36
fransmarcelissen wrote:
If there are alternatives for {INSERTANS:{SGQ}}, thats fine. It "breaks" the principle of upwards compatibility with 1.91, however.

fransmarcelissen-

1.92 is intended to be upwards compatible from 1.91 for all supported features. There are many work-arounds that aren't inherently supported, so not all of those may work in 1.92 (however I tried to support them anyway). This is the first I'm hearing of the goal of using {INSERTANS:{SGQA}}, so I didn't plan for it, and it would probably be difficult to support.

That notwithstanding, I'll still see whether I can support "this".

I'm still not understanding your use case, however. You're trying to set an answer to a computedValue. You can use EM to generate any computedValue you want, and default values can also be equations, so you should be able to implement what you're talking about with EM. Can you give more information about what you're trying to do with those computed values?

/Tom
The administrator has disabled public write access.
  • Page:
  • 1
  • 2
Moderators: ITEd
Time to create page: 0.247 seconds
Donation Image