WeBWorK Problems

Draggable Proof issue

Draggable Proof issue

by Paul Seeburger -
Number of replies: 7

I'm having an issue with a draggable proof problem (the first I have assigned to students).  It's actually one of Paul Pearson's, although I modified it.
It's a version of: Library/Hope/Multi1/01-05-Lines-planes/Lines-planes-strategy-01.pg

The options the student selected are disappearing after the second time they submit their answers.

My issue with this draggable proof problem looks like exactly the same issue as happened in this forum post.


But I don't have the draggableproofs.pl file in my macros folder.  And I don't directly control the version of WeBWorK being used on my server.

It appears we are using WeBWorK version 2.15+develop on the server I use at the U or R, but I am reading on the forums about version 2.17 being current.

My CSS styling is the older version and the options are disappearing on the right after the student submits the answer twice.

Any ideas on how I can fix this?

Thanks so much!

Paul

In reply to Paul Seeburger

Re: Draggable Proof issue

by Glenn Rice -

The current version of WeBWorK is 2.18.

The draggableProof.pl macro you are using with WeBWorK 2.15 (if there is not one in the course templates directory) would be the one in the OPL. That version was rather old and didn't work well. The only fix that I know of would be to use the macro with newer versions of WeBWorK.

In reply to Glenn Rice

Re: Draggable Proof issue

by Paul Seeburger -
So it looks like I am stuck on version 2.15 through this semester. Is there any way you could suggest that I could avoid this error (of losing the choices in the right column after the student submits the answer twice) on this version with draggable proofs?

I tried putting the latest draggableProofs.pl in my macros folder (from the new development: https://github.com/openwebwork/pg/blob/main/macros/math/draggableProof.pl) but then I get other errors about ADD_JS_FILE not being present. Deleting these ADD_JS_FILE lines and trying to place these files appropriately in my course also does not seem to be easy, as I don't know where to place them correctly (if it's even possible).

Thanks!

Paul
In reply to Glenn Rice

Re: Draggable Proof issue

by Paul Seeburger -

Ok, I have an idea for a possible temporary solution, but I don't understand the code well enough to know how to implement it.

It appears that the options in the left column are kept the same, if saved, or recreated as the complement of the right column, if not.

Since sometimes the right column is going blank (and thus losing all those options), I want to make the left column always be the complement of the right side.  This should do the trick, as a stop-gap, as my students will always have all the options to work with.  (Right now the options that disappeared are not available to continue working on the problem.)

Here's the code that I believe is relevant in the github version of draggableProof.pl.  In particular it appears that the last code block below needs the adjustment.

sub GetAnswer {
  my $self = shift; my $previous;

  # Retrieve the previous state of the right column.
  $previous = $main::inputs_ref->{$self->{tgtAns}} || "";
  $previous =~ s/$self->{id}-//g; $self->{previousTarget} = [split(/,/,$previous)];

  # Calculate the complement of the right column.
  my %prevTarget = map {$_ => 1} @{$self->{previousTarget}};
  my @diff = grep {not $prevTarget{$_}} (0..$self->{numProvided}-1);

  # If the previous state of the left column has been saved, use it. (This ensures that the tiles 
  # in the left column are kept in the same order that the user had arranged them). If it has not
  # been saved, use the complement of the right column.
  $previous = $main::inputs_ref->{$self->{srcAns}} || "$self->{id}-".join(",$self->{id}-",@diff);
  $previous =~ s/$self->{id}-//g; $self->{previousSource} = [split(/,/,$previous)];
}

What should I change so the left column is always the complement of the right column?

Thanks so much!

Paul

In reply to Paul Seeburger

Re: Draggable Proof issue

by Alex Jordan -

This line:

$previous = $main::inputs_ref->{$self->{srcAns}} || "$self->{id}-".join(",$self->{id}-",@diff);

Is like:

$previous = A || B;

That means if A is true in the perl sense, $previous will be set to A. Otherwise if B is true, then B. So I'm guessing from the comment above you would just remove the A portion and see if that works for what you want.



In reply to Alex Jordan

Re: Draggable Proof issue

by Paul Seeburger -
Thanks, Alex!

This worked! The left side now repopulates with all the elements when the right side goes blank after the second submit of the same ordering.

But it would be even better if I could keep the problem from blanking out the right column on the second submit of the same answer in the first place. Do you have any ideas how to accomplish this in the OPL github version of draggableProofs.pl?

Again this is just a stop-gap solution for use in older versions of WeBWorK, but I'd guess some other people may be in a similar situation. I had thought the draggable proofs had been a fairly stable problem type for a number of years. But I had not used one before this semester.

Thanks so much!

Paul
In reply to Paul Seeburger

Re: Draggable Proof issue

by Glenn Rice -

Unfortunately, the version of the draggableProofs.pl macro in the OPL has lots of problems.  That is why it was rewritten (twice now).  The updated macro no longer uses the obsolete jquery nestable library, and uses a more modern drag and drop javascript library.  It also works in gateway tests, and the OPL version did not.  The updated macro also uses PG Perl modules (lib/DragNDrop.pm), and so it would be rather challenging to backport it to older versions of WeBWorK.

I am sorry, but I don't want to revisit the old version of that macro and try to fix it again.  The newer version is so much better.

In reply to Glenn Rice

Re: Draggable Proof issue

by Paul Seeburger -

I can understand.

The fix Alex helped me work out makes these problems usable for now, if a little buggy.  I am glad that this type of problem is finally going to be stable in the newest versions of WeBWorK (2.17 or newer).  It's been a really impressive-looking problem type for years.

Paul