on branching

[Yuri]

I'm tryng to do by myself, but I've lot of difficulties on
understanding the code.

for example:

if self.getRequiredQuestion() !=
next_page.getRequiredQuestion():

in SubSurvey.py, around line 183, is stopping the survey to branch on
another subsurvay depending on the same question.

for example

a b c

a is a select
b depends on a
c depends on a

only b is executed. The test prevent to c to be executed, I don't
understand why :)

[Yuri]

If I replace it with if 1==1: (always true) seems to work...

I've also modified the tests on Survey.py and Subsurvey.py from:

if question.getAnswerFor(userid) == next_page.getRequiredAnswer()

to

if question.getAnswerFor(userid) in
next_page.getRequiredAnswer().split(' ')

and I can branch on multiple answer, separating them with spaces :)

So I can now put Yes No and branch on Yes or No.

I'm going to do more tests.

[Yuri]

another bug:

on line 154 of SubSurvey.py change:

next_page = pages[current_page+2]

to

next_page = pages[current_page+1]


now we can support kind of surveys as in flow.png you can find in file
section of this group :)

[Michael Davis]

Hi Yuri,

Sorry, been away on holiday.

The code looks rather clunky and could do with a tidy up. The other problem
is that there is an assumption that there can be only one required question
for a sub survey. Solving multiple options by splitting on a space would be
bad, answers may have a space in them which would mean any question with an
answer with a space may break your branch conditions.

I think it would be better to work on a branch for this. You're also working
from an out of date version, since a lot of code has been moved around you
will have a problem merging your changes back in with the trunk.

My feeling on complex branching is more on the edit form side. Once you have
the data storage side sorted out, with an appropriate widget to modify the
data, the logic behind it to utilise the conditions should be fairly simple.

If you could cut a branch for this from the current trunk, I can give you a
hand with it.

What I was thinking was that you should be able to add multiple questions,
each with one or more options. Dropping the ability to choose whether these
are positive or negative options would make it simpler without losing any
functionality. The possible questions to add as conditions should be
restricted to questions before that sub survey. I think a special widget is
going to be needed for this. The trick is going to be keeping backward
compatibility.

Cheers
Michael

[Yuri]

On 5 Ago, 20:55, Michael Davis <M.R.Da...@cranfield.ac.uk> wrote:
> Hi Yuri,
>
> Sorry, been away on holiday.

Holiday are a must :)

>
> The code looks rather clunky and could do with a tidy up.

Very clunky and undocumented. For example the pages[current_page + 2]
made me impressed :)

> The other problem
> is that there is an assumption that there can be only one required question
> for a sub survey.

I know, but this can be avoided rescanning all the survey to see what
belongs to the subsurvey. It is a one line change.

> Solving multiple options by splitting on a space would be
> bad, answers may have a space in them which would mean any question with an
> answer with a space may break your branch conditions.

We could split by |, as other plone products do.

> I think it would be better to work on a branch for this. You're also working
> from an out of date version, since a lot of code has been moved around you
> will have a problem merging your changes back in with the trunk.

I know, but the changes are minimal and I don't think the subsurvey.py
or survey.py code has changed too much.

> My feeling on complex branching is more on the edit form side. Once you have
> the data storage side sorted out, with an appropriate widget to modify the
> data, the logic behind it to utilise the conditions should be fairly simple.

I agree, a tool to manage this would help, and a graph like syntax
(did you remember my idea in Naples to use a workflow like schema?)
could solve it.

In the mean time, supporting branching on multiple question, and
avoiding the assumption there's only one subsurvey can help us to
solve out most of our use cases.

> If you could cut a branch for this from the current trunk, I can give you a
> hand with it.

I'm still in the "hack and test phase", but if you can review the 3
changes I've made. This could help a lot.

> What I was thinking was that you should be able to add multiple questions,
> each with one or more options. Dropping the ability to choose whether these
> are positive or negative options would make it simpler without losing any
> functionality. The possible questions to add as conditions should be
> restricted to questions before that sub survey.

This is not a problem, cause you'll never branch on a question you've
still to answer :) so no putting restrictions would be the policy.

> I think a special widget is
> going to be needed for this.

Or just syntax. You can put a python expression to be evaluated, so
people could do what they need directly. For example:

- map all the values to <id_of_the_question>_value

python: (<id_of_a_question>_value in ['a','b','c'] or
<id_of_another_question>_value <> 'Wrong') and
<id_of_yet_another_question>_value == 'Yes'

there are few lines in survey.py and subsurvey.py that manages this.
I'm going to write a function which replaces the checks.

I mean, we can semplify a lot the getNextPage function .This could be
a python script, for example, so people could customize it.

How getNextPage works now (correct me if I'm wrong) is:

If I'm on a survey, I just check if there's a subsurvey or end
If I'm on a subsurvey, scan all the subsurvey from me to ahead (using
the order of folder contents) and find the first one that is ok to the
branch condition on itself or without a condition.

My changes just cancel the check which implies that the subsurvey is
followed only if it is the next one. Now I check only if a SubSurvey
obey to the condition.

If we scan from the first one to the current, only on subsurvey with
condition, we could be better and go back. For example, we can put a
subsurvey on second position which has a condition on the 4th
subsurvey. After the 4th, rescanning would me go to the 2nd one, and I
can redo the path. So we can introduce circular surveys.

a -> b -> e -> h -> b -> c -> end

I think there's no reason to do this, but the point is that deleting
checks we can do almost everything.

> The trick is going to be keeping backward
> compatibility.

Why? I mean, after the 1.2.2 and plone 3 compatibility (I think we are
already there), you can call it PloneSurveyNG and have another
product, they could both live toghether.

>
> Cheers
> Michael

[Davis, Michael]

Hi Yuri,

Sorry, must have hit enter by mistake.

The survey assumes linearity. So you move from first page to end with no going backwards. A page only is displayed if the branching conditions are met, if not it is skipped and will not reappear. Introducing non-linearity will cause a problem. If you rescan each page for the conditions each time, all pages already answered will presumably still be true, and having a feedback loop will make the survey design more complex.

I don't think it's a good idea either to force survey designers to learn python to make their branching conditions. Some kind of widget combo should be used so they can select which questions and which answers of each question should be met for that page to appear. If you are time pressed for solving this, some kind of data structure that you can enter in a text widget would do it. The python behind it for evaluating whether a set of conditions are met should pick up from the data structure and check the conditions. For example, using a list of dicts should do it, eg [{'question_id':'q1', 'answers':['yes','No',]}, {'question_id':'q4', 'answers':['yes','maybe',]},]. This can be returned by a getConditions method, which picks it up from however the widget works.

I think circular or repeating portions of a survey are a different problem, and should be solved in a different way.

If you send me a patch, I can have a look at where you're going easier.

Cheers
Michael

[Yuri]

On 6 Ago, 10:47, "Davis, Michael" <m.r.da...@cranfield.ac.uk> wrote:
> Hi Yuri,
>
> Sorry, must have hit enter by mistake.
>
> The survey assumes linearity. So you move from first page to end with no going backwards. A page only is displayed if the branching conditions are met, if not it is skipped and will not reappear. Introducing non-linearity will cause a problem. If you rescan each page for the conditions each time, all pages already answered will presumably still be true, and having a feedback loop will make the survey design more complex.

I agree, it was just to show how easy can getNextPage wherever we
want :)

>
> I don't think it's a good idea either to force survey designers to learn python to make their branching conditions.
>

Well, it could be an "advanced option" on a different tab :P

[Yuri]

I've sent you the patch, with a zexp of a survey and a picture.

It has some logging, basically to follow where it goes in getNextPage.

[Michael Davis]

Hi Yuri,

Thanks for that, what version of plone are you using? I couldn't import it.

Your complex survey seems linear with single question, but needs multiple
response options for a question.

As you say patch seems to be mostly logging. Will help out where I can, let
me know.

Cheers
Michael

[Yuri]

On 7 Ago, 00:33, Michael Davis <M.R.Da...@cranfield.ac.uk> wrote:
> Hi Yuri,
>
> Thanks for that, what version of plone are you using? I couldn't import it.

it is plone 3.1.4

>
> Your complex survey seems linear with single question, but needs multiple
> response options for a question.

Yes, but it also goes to a subsurvey even if it is not the next one.

>
> As you say patch seems to be mostly logging. Will help out where I can, let
> me know.

other than loggin, it is 3 line changes which changes the behaviour of
ps, letting multiple choice on select and display a subsurvey if it
meet the condition, even if it is not the next one.

>
> Cheers
> Michael