Log of /branches/rel-2-3-dev/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm
Parent Directory
Revision
4859 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Wed Mar 7 20:54:41 2007 UTC (6 years, 2 months ago) by
sh002i
File length: 56051 byte(s)
Diff to
previous 4854
backport (sh002i): setting $this_set='' is unnecessary. getMergedSet
returns undef in scalar context if the record is not found. also fixed
some indentation.
Revision
4854 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Wed Mar 7 18:14:55 2007 UTC (6 years, 2 months ago) by
sh002i
File length: 56228 byte(s)
Diff to
previous 4643
backport (glarose): Make sure that something gets passed to
renderProblems() for the userSet even when a global set is being edited
and it isn't assigned to any users. Gets rid of "odd number of elements
in hash assignment" errors in renderProblems. Because renderProblems
plugs in a fake set if it gets a false value in for the userSet, sending
in '' appears to solve the problem.
Revision
4430 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Fri Sep 1 15:47:25 2006 UTC (6 years, 8 months ago) by
sh002i
File length: 56043 byte(s)
Diff to
previous 4396
backport (glarose): Gateway update of ProblemSetDetail: add some
sensible defaults for gateway parameters, remove confusing labels.
Revision
3802 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Thu Dec 8 19:16:09 2005 UTC (7 years, 5 months ago) by
sh002i
Original Path:
trunk/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm
File length: 55407 byte(s)
Diff to
previous 3790
Allow reordering to succeed even if some UserProblems are missing.
Addresses bug #878.
By the way, I found the reordering code really hard to read, so I added
a lot of comments and replaced multidimensional array accesses with a
shorter form. ($sortme[$j][0] rather than $sortme[$j]->[0].) I'd like to
maybe rewrite this code sometime to eliminate some indirection and make
things clearer.
There are two substantive changes:
(1) When a UserProblem has to get reordered, we only reorder it if a
UserProblem record actually exists. If it doesn't exist, we figure out
where it would have moved to, and delete that problem instead.
(2) When moving a UserProblem, the target location either contains or
doesn't contain a record. Previously, the code checked whether a
GlobalProblem existed in this location, assuming that if a global
problem existed the corresponding UserProblem would as well. Now, it
checks whether a UserProblem exists, which allows for missing
UserProblem records.
Lingering questions:
(1) When multiple problems are assigned the same number, this results in
the last one ending up first in the new ordering. I think it would be
more natural for the first one to end up first. This would be an easy
fix.
(2) $force always gets set if reordering needs to be done, so we aren't
able to delete a problem, reorder some other problems, and end up with a
hole where where the deleted problem was. We can either fix this by
mentioning this next to the force checkbox, or change it so that
particular holes (i.e. those left by deleted problems) are allowed when
reordering.
Revision
3719 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Mon Oct 17 13:58:07 2005 UTC (7 years, 7 months ago) by
gage
Original Path:
trunk/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm
File length: 50908 byte(s)
Diff to
previous 3647
Improved handling of case where a blank_problem is asked for in PGProblemEditor.pm
Also improved the random names for new local problems
Added ability to create a new blank problem in ProblemSetDetail.pm (without going to the PGProblemEditor.pm)
however something is not yet working when this problem record is saved.
Sam -- could you look at
lines near 679 to see what the problem is? There is a FIXME note there. I suspect that the addProblemToSet
routine is failing somehow, but there is no error message. Many of the record fields are not filled out --
including the sourceFile path and the number of attempts. The same snippet of code works fine
in PGProblemEditor.pm
--Mike
Revision
3377 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Thu Jul 14 13:15:27 2005 UTC (7 years, 10 months ago) by
glarose
Original Path:
trunk/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm
File length: 48413 byte(s)
Diff to
previous 3175
Preliminary commit of changes to add Gateway module.
This adds to WeBWorK
- the ability to create versioned, timed problem sets ("gateway tests")
for which all problems are displayed on a single page ("versioned"
means that students can get multiple versions of the problem set),
- the ability to create sets that draw problems from groups of
problems, and
- the ability to create sets that require a proctor login to start
and grade.
Sets can be defined as gateway tests or proctored gateway tests from
the ProblemSetDetail page.
Not quite bug-free yet. Known bugs include handling of problem values
on the Student Progress page (I think this may be a problem with
changing from sql database format where all entries were 'text' to
sql_single in ver 2.1, where they are integer), and a division by zero
error on the grades page (which may be the same problem).
Tests with a number of attempts per version greater than one haven't
been carefully tested, nor has scoring of gateway tests.
Revision
2913 -
(
view)
(
download)
(
as text)
(
annotate)
-
[select for diffs]
Modified
Wed Oct 13 01:55:15 2004 UTC (8 years, 7 months ago) by
sh002i
Original Path:
trunk/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetDetail.pm
File length: 44698 byte(s)
Diff to
previous 2904
optimizations in database access (makes a big difference).
My notes:
Here's the initial timing data for a set with 10 problems:
TIMING 57300 2 1097622363.881851 (16.734902) mth162: END (assumed)
$mergedRecord is never used in FieldHTML(). However, it is populated
with a merged set or problem, which requires two database calls and a
merge operation. It appears to be OK to get rid of these calls
altogether.
TIMING 57582 0 1097624803.340321 (11.219321) mth162: END (assumed)
i'm not as worried about the several DB calls in
handle_problem_numbers(), since that only happens when "Save Changes" is
clicked. not looking at those for now...
in initialize(), the global set is fetched from the database at the
beginning (and put into $setRecord). then it is fetched again in two
places, first in a conditional if the "submit_changes" param is defined,
and then in the following conditional, when "submit_changes" is defined
and there was no error. taking this out...
(those conditionals are pretty weird to begin with. i would have
expected something more like "if (submit_changes) { ... unless (error) {
... } }". probably from grafting code together?)
ok, the big one is getting pre-fetched records into FieldHTML. I added
$setRecord and $problemRecord parameters to FieldHTML (and $Set and
$Problem parameters to FieldTable to pass through to FieldHTML), and
pre-fetch GlobalProblems, UserProblems, and MergedProblems en masse
before going through the problem IDs in body().
TIMING 58456 0 1097632191.012939 (4.516615) mth162: END (assumed)
And it's only a little more than that when viewing for a particular
user:
TIMING 58453 0 1097632169.074723 (6.513201) mth162: END (assumed)
This form allows you to request diffs between any two revisions of this file.
For each of the two "sides" of the diff,
enter a numeric revision.
