<p>I found an answer to the second part of the question here <a href="https://github.com/oTree-org/otree-docs/issues/2" rel="nofollow">https://github.com/oTree-org/otree-docs/issues/2</a>.</p>

<p>It turns out that in <code>oTree</code>,  the variable <code>form</code> which is passed to the template is iterable. Thus one the following code does the job:</p>

<pre><code>{% for field in form %}
        {% formfield field %}
    {% endfor %}
</code></pre>

<p>Regarding the first part of the question, I contacted a programmer working at oTree. He confirmed that, in its current version, oTree can only define a fixed number of field. He advised to define in <code>model.py</code> a large maximal number of fields and then use <code>get_form_fields</code> in views.py to dynamically return a list with desired subset of fields.</p>

<p>Notice that if you want to create a really large maximal number of fields, the trick presented in the question using <code>loop</code> and <code>exec</code> remains — I believe — the easiest way to proceed.</p>

CC BY-SA 3.0
2015-09-16T14:08:07.750Z
2016-01-07T05:33:10.920Z
2016-01-07T05:33:10.920Z
Martin Van der Linden
<p>I am building a lab experiment through <a href="http://www.otree.org/" rel="nofollow">otree</a>, ``a Django-based framework for implementing multiplayer decision strategy games." </p>

<p><strong>Basics about otree's forms</strong></p>

<p>Here is an example of how otree gets the players to report their choices (based on the "matching_pennies" game which is part of the templates provided by otree).</p>

<p>In a file named <code>model.py</code>, one finds the following code</p>

<pre><code>class Player(otree.models.BasePlayer):

[...]

penny_side = models.CharField(choices=['Heads', 'Tails'])

[...]
</code></pre>

<p>Then in <code>views.py</code> one finds</p>

<pre><code>class Choice(Page):

form_model = models.Player
form_fields = ['penny_side']
</code></pre>

<p>Finally, the form is displayed to the end user through <code>choice.html</code> by inserting</p>

<pre><code>{% formfield player.penny_side with label="I choose:" %}
</code></pre>

<p><strong>What I would like to do</strong> </p>

<p>is create a flexible experiment in which the number of choices that players have to make varies with a parameter <code>x</code>. That is, I want the whole framework to generate <code>x</code> possible choices by just setting a parameter <code>x</code>, and not having to go update all the files manually. This is in order to make my life easier if we ever change the experimental design, and to make the code useful to others with different experimental design (I plan to release it on Github at some point).</p>

<p>It seems like it should be fairly easy to do with a couple of loops, but I am having trouble using lists given the way <code>otree</code> is structured. </p>

<p>From what I understand,  I only see one <em>very nasty</em> way to have the number of choices depend on a parameter <code>x</code>. I first give each choice a different name in <code>model.py</code>, e.g.</p>

<pre><code>class Player(otree.models.BasePlayer):

[...]

for i in range(x):
        exec("""choice%d = models.IntegerField(
        choices= ['Heads','Tails'])""" %i)

[...]
</code></pre>

<p>then pass the name of all those choices along to <code>view.py</code>, e.g.</p>

<pre><code>class Choice(Page):

all_forms = list()
for i in range(x):
    all_forms.append('choice%d' %i)

form_model = models.Player
form_fields = all_forms
</code></pre>

<p>and finally, find a way to loop through all the forms in Choice.html; something like (I know the code below does not work, just to give the gist of it)</p>

<pre><code>{% for p in range(x)  %}

{% formfield player.choice{{p}} with label="I choose:" %}

{% endfor %}
</code></pre>

<p><strong>My question are:</strong></p>

<ul>
<li>This is all very dirty, and looks overly complicated : lists have been invented to avoid this kind of crazy naming process. Do you see a way to make this work with lists instead?</li>
<li>If that's the only way to hack into otree and have the number off choices depend on a parameter <code>x</code>, so be it. But I am still unable to figure out a way to generate the desired set of forms via a loop in Django (obviously the example above does not work, for many reasons.).</li>
</ul>

CC BY-SA 3.0
2015-09-11T02:21:39.807Z
See http://meta.economics.stackexchange.com/questions/1432/questions-about-programming-lab-experiments for a discussion on whether this kind of question is appropriate here.
Martin Van der Linden
CC BY-SA 3.0
2015-09-15T18:46:06.693Z
i think you would get a better result using the regular stack exchange. My python questions get answered quickly on there. This is definitely more of a language question than economics.
lost
CC BY-SA 3.0
2015-09-15T20:38:24.313Z
@lost: I thought so too and first published the question on Stackoverflow, but the question did not get any attention. My hope posting it here was to come across users who are familiar with otree. From what I understand of the problem, someone with a good knowledge of otree might do a better job at answering than someone knowing Pyhton/Django. Anyways, might have to give another try at Stackoverflow eventually...
Martin Van der Linden
CC BY-SA 3.0
2015-09-17T18:58:05.983Z
I think this is a perfectly valid Econ.SE question. oTree and zTree are languages almost exclusively used in economics (and probably polsci). However, I don't think there are many experimental economists here, so I would be surprised to see an answer to this question.
The Almighty Bob
CC BY-SA 3.0
2015-09-17T19:01:23.313Z
Btw, I think that lab-experiment is too similar to experimental-economics, but I didn't really wanted to edit your question for this.
The Almighty Bob
CC BY-SA 3.0
2015-09-17T21:33:32.740Z
@The Almighty Bob : you're probably right about the tag. We might need a discussion on meta to decide whether keeping the two tags is worth it. Maybe I'll start it later if I remember.
Martin Van der Linden
<software><experimental-economics>
Flexible lab experiment in otree
Martin Van der Linden
# Flexible lab experiment in otree

(Asked by: username_0 on 2015-09-11)

I am building a lab experiment through [otree](http://www.otree.org/), ``a Django-based framework for implementing multiplayer decision strategy games."

**Basics about otree's forms**

Here is an example of how otree gets the players to report their choices (based on the "matching\_pennies" game which is part of the templates provided by otree).

In a file named `model.py`, one finds the following code

```
class Player(otree.models.BasePlayer):

[...]

penny_side = models.CharField(choices=['Heads', 'Tails'])

[...]

```

Then in `views.py` one finds

```
class Choice(Page):

form_model = models.Player
form_fields = ['penny_side']

```

Finally, the form is displayed to the end user through `choice.html` by inserting

```
{% formfield player.penny_side with label="I choose:" %}

```

**What I would like to do**

is create a flexible experiment in which the number of choices that players have to make varies with a parameter `x`. That is, I want the whole framework to generate `x` possible choices by just setting a parameter `x`, and not having to go update all the files manually. This is in order to make my life easier if we ever change the experimental design, and to make the code useful to others with different experimental design (I plan to release it on Github at some point).

It seems like it should be fairly easy to do with a couple of loops, but I am having trouble using lists given the way `otree` is structured.

From what I understand, I only see one *very nasty* way to have the number of choices depend on a parameter `x`. I first give each choice a different name in `model.py`, e.g.

```
class Player(otree.models.BasePlayer):

[...]

for i in range(x):
        exec("""choice%d = models.IntegerField(
        choices= ['Heads','Tails'])""" %i)

[...]

```

then pass the name of all those choices along to `view.py`, e.g.

```
class Choice(Page):

all_forms = list()
for i in range(x):
    all_forms.append('choice%d' %i)

form_model = models.Player
form_fields = all_forms

```

and finally, find a way to loop through all the forms in Choice.html; something like (I know the code below does not work, just to give the gist of it)

```
{% for p in range(x)  %}

{% formfield player.choice{{p}} with label="I choose:" %}

{% endfor %}

```

**My question are:**

* This is all very dirty, and looks overly complicated : lists have been invented to avoid this kind of crazy naming process. Do you see a way to make this work with lists instead?
* If that's the only way to hack into otree and have the number off choices depend on a parameter `x`, so be it. But I am still unable to figure out a way to generate the desired set of forms via a loop in Django (obviously the example above does not work, for many reasons.).

**Tags:** software, experimental-economics

> **Comments:**
> **username_0**: See http://meta.economics.stackexchange.com/questions/1432/questions-about-programming-lab-experiments for a discussion on whether this kind of question is appropriate here.  
> **username_1**: i think you would get a better result using the regular stack exchange. My python questions get answered quickly on there. This is definitely more of a language question than economics.  
> **username_0**: @username_1: I thought so too and first published the question on Stackoverflow, but the question did not get any attention. My hope posting it here was to come across users who are familiar with otree. From what I understand of the problem, someone with a good knowledge of otree might do a better job at answering than someone knowing Pyhton/Django. Anyways, might have to give another try at Stackoverflow eventually...  
> **username_2**: I think this is a perfectly valid Econ.SE question. oTree and zTree are languages almost exclusively used in economics (and probably polsci). However, I don't think there are many experimental economists here, so I would be surprised to see an answer to this question.  
> **username_2**: Btw, I think that lab-experiment is too similar to experimental-economics, but I didn't really wanted to edit your question for this.  
> **username_0**: @username_2 : you're probably right about the tag. We might need a discussion on meta to decide whether keeping the two tags is worth it. Maybe I'll start it later if I remember.  

---

## 1 answers

### Answer by username_0 on 2015-09-16. Score: 2 | Accepted answer

I found an answer to the second part of the question here <https://github.com/oTree-org/otree-docs/issues/2>.

It turns out that in `oTree`, the variable `form` which is passed to the template is iterable. Thus one the following code does the job:

```
{% for field in form %}
        {% formfield field %}
    {% endfor %}

```

Regarding the first part of the question, I contacted a programmer working at oTree. He confirmed that, in its current version, oTree can only define a fixed number of field. He advised to define in `model.py` a large maximal number of fields and then use `get_form_fields` in views.py to dynamically return a list with desired subset of fields.

Notice that if you want to create a really large maximal number of fields, the trick presented in the question using `loop` and `exec` remains — I believe — the easiest way to proceed.


---

