Doug,
The number of calls to &EXT() can be reduced by replacing these lines:
if ($tries) {
for (my $i=$version; $i>=1; $i--) {
last if (&EXT("user.resource.$i:resource.0.regrader"));
with:
$regrader=&EXT('user.resource.resource.0.regrader');
if ($tries) {
for (my $i=$version; $i>=1; $i--) {
last if (($regrader) &&
(&EXT("user.resource.$i:resource.0.regrader")));
Stuart Raeburn
LON-CAPA Academic Consortium
________________________________________
From: Raeburn, Stuart
Sent: Wednesday, October 10, 2018 4:28 PM
To: Discussion list for LON-CAPA users
Subject: Re: [LON-CAPA-users] Differentiate between tries when a problem is
reset?
Doug,
Your script block in /res/uiuc/dmills/andino/CurvedArrows/CAAD2-2.problem
contains:
$tries=(&EXT('user.resource.resource.1.tries'))?
&EXT('user.resource.resource.1.tries') : 0;
#loop through the number of attempts and build an $attempts variable
for my $i (1..$tries) {
push @attempts, &EXT("user.resource.$i:resource.1.ans.submission");
}
The index used internally in LON-CAPA for each submission record need not
correspond to the current number of tries, because LON-CAPA records each
submission, including those that do not cost a try, such as submission of a
previously submitted (incorrect) answer. So you should loop over number of
transactions instead of number of tries. (In LON-CAPA the transaction number
is called the version). To suppress display of any submissions made prior to an
instructor reset, for a partID of 0 , for a responseID of 'ans' use the
following:
#looping from newest attempt to oldest attempt, and populating an array with
submissions for response ID 'ans' in part: 0
#submissions which do not cost a try are not included.
#looping stops if an instructor reset is encountered.
#the resulting array of submissions to display is ordered from oldest to newest.
@attempts=();
$tries=0;
$version=&EXT('user.resource.version');
if ($version) {
$tries=&EXT('user.resource.resource.0.tries');
if ($tries) {
for (my $i=$version; $i>=1; $i--) {
last if (&EXT("user.resource.$i:resource.0.regrader"));
next if (&EXT("user.resource.$i:resource.0.tries") eq '');
unshift(@attempts,&EXT("user.resource.$i:resource.0.ans.submission"));
}
}
}
If you wanted to also include submissions from transactions which did not cost
a try in the attempts array replace
next if (&EXT("user.resource.$i:resource.0.tries") eq '');
with
next if (&EXT("user.resource.$i:resource.0.ans.submission") eq '');
and omit the if ($tries) condition.
Because this loop could result in lots of calls to &EXT(), and thereby load
your server, it would be prudent to hard code a maximum number allowed for
$version, and include an <instructorcomment></instructorcomment> block to
document that.
Stuart Raeburn
LON-CAPA Academic Consortium
________________________________________
From: LON-CAPA-users <lon-capa-users-boun...@mail.lon-capa.org> on behalf of
Mills, Douglas G <dmi...@illinois.edu>
Sent: Wednesday, October 10, 2018 11:51:31 AM
To: lon-capa-users@mail.lon-capa.org
Cc: Mills, Douglas G
Subject: Re: [LON-CAPA-users] Differentiate between tries when a problem is
reset?
Hi All,
Looking back through older emails I came across the unanswered question below.
I thought perhaps sharing an example of this might help. Here is one of these
problems published for public access (no authentication required but of course
automatically in practice mode):
http://lon-capa.illinois.edu/res/uiuc/dmills/andino/CurvedArrows/CAAD2-2.problem<https://urldefense.proofpoint.com/v2/url?u=http-3A__lon-2Dcapa.illinois.edu_res_uiuc_dmills_andino_CurvedArrows_CAAD2-2D2.problem&d=DwMGaQ&c=nE__W8dFE-shTxStwXtp0A&r=VsGo3jOm8tGLd6f-KlhT-g&m=fZS1vrYiuyCYNn4oImEjX4r_J3yLINqVnl5m3iWhEdk&s=-Cw5K9ZxVa4xFiJrO-m-zkHfPgTu4fJzG0YzbbnCsDI&e=>
(works most nicely in Chrome but will work in other browsers as well).
If you give it a go, you'll see that when you've made a submission it adds an
attempt link so that you can go back and look at your previous submissions in a
meaningful way (previous tries shows information used for the display, not
really anything meaningful to a student). Because the instructor I am working
with on this envisioned giving students only 12 tries on this type of problem,
currently it will only display 12 tries (the public version linked above of
course has unlimited tries since it is in practice mode, but providing the
links to previous tries will fail after 12 tries).
What I've discovered is that IF the instructor for some reason needs to reset
the problem for a student, it starts over again as it should BUT after they've
made a first try, if they click on the "attempt 1" link, it will display not
their first try after the reset, but their very first try from before the
problem was reset. My question then is, is there some way to identify if there
has been a reset that I could make use of to start again with the tries after
the reset? It's not a huge deal -- resetting won't occur often, but it's an
annoyance and I do have other problem types that provide links to view previous
attempts as well where I'm sure this is a potential problem.
Thanks as always for any hints clues or advice that can be provided!
Doug
Douglas Mills
Director of Instructional Technology
Department of Chemistry
University of Illinois
From: "Mills, Douglas G" <dmi...@illinois.edu>
Date: Wednesday, April 4, 2018 at 3:52 PM
To: Discussion list for LON-CAPA users <lon-capa-users@mail.lon-capa.org>
Cc: "Mills, Douglas G" <dmi...@illinois.edu>
Subject: Differentiate between tries when a problem is reset?
HI All,
I've created a problem where viewing previous tries the normal way is not very
meaningful to the students and so am referencing their attempts and giving them
a series of links they can click on to display a visualization of their
previous attempts. This all works fine. However, in the case where for whatever
reason the instructor RESETS the student's access to the problem so that they
can start over, Lon-Capa maintains the record of their attempts from before the
reset and continues to reference those. I'm wondering, therefore, if there is
some way in the event of an access reset to differentiate between the new
attempts vs. the old (pre-reset) attempts.
user.resource.resource.<partid>.tries resets so that the number of tries is
again 0, 1, 2, etc. but
user.resource.1:resource.<partid>.<responseid>.submission continues to keep
track of ALL submissions. I'm sure I'm missing something simple. Thanks for
your help!
Doug
Douglas Mills
Director of Instructional Technology
Department of Chemistry
University of Illinois
_______________________________________________
LON-CAPA-users mailing list
LON-CAPA-users@mail.lon-capa.org
http://mail.lon-capa.org/mailman/listinfo/lon-capa-users
