Re: [WWdevel] testing and showing results

[Sam H. <sh...@ma...>]

on 11/29/06 9:25 AM P. Gavin LaRose said the following:

> Hi all,
> 
> I'm in the process of converting our old (MapleTA) on-line placement test 
> into a new (WeBWorK) version, and have come across the following: MapleTA 
> allows a homework set (or test) to show the score or not, and the correct 
> answers, or not, once the set (or test) has been submitted for a grade. 
> For our placement test this is a good thing: we don't want people printing 
> out copies of the test, and because the score on the test is just one of 
> several factors determining a student's placement it's generally regarded 
> as a good thing to avoid having the student see how s/he did on the test 
> before talking with an advisor about her/his math placement.
> 
> This is, of course, not what WeBWorK does.  The easiest way I can see to 
> add this capability to WeBWorK, and/or the WeBWorK gateway tests, is to 
> add (another) column to the set table in the database.  Let's call it 
> hide_results.  Then if this column has the value 0 (or null, if that's 
> still allowed in the database) we behave as usual.  Other settings could 
> include 1 - hide the problems but report a score (for a gateway assignment 
> this should be easy to implement; for a homework, it might be a little 
> harder, but I think it shouldn't be bad); or 2 - just report that the 
> score was saved but return no data about the score.
> 
> (1) Does anyone else have a use for something like this, or see it as
>    potentially useful?  In particular, should it be a gateway/quiz feature
>    to the exclusion of homework?

I think this should apply to all types of problem sets, not just gateway 
tests. Should probably apply to individual problems as well as entire 
sets as well.

Giving the professor more control over WeBWorK's behavior is generally a 
good thing (as long as the defaults are reasonable).

I'd suggest having separate fields for each facet of this behavior, or 
at least more descriptive values than 0, 1, and 2.

> (2) Is it a problem to add another field to the database tables?  (i.e.,
>    has Sam's fevered work in the background to deal with those of me who
>    keep adding fields finally made it extensible to the point of dealing
>    with these gracefully?)

Yes, it's pretty easy since 2.3.0 -- the procedure is as follows:

(1) Add code to bin/wwdb_upgrade to add the field(s).
(2) Add the field(s) to the appropriate record classes.

The code in wwdb_upgrade will look something like this:

$DB_VERSIONS[++$i]{desc} = "adds my_new_field field to set and set_user 
tables of each course.";
$DB_VERSIONS[  $i]{course_code} = sub {
	my $course = shift;
	$dbh->do("ALTER TABLE `${course}_set` ADD COLUMN `my_new_field` INT")
		if exists $sql_tables{"${course}_set"};
	$dbh->do("ALTER TABLE `${course}_set_user` ADD COLUMN `my_new_field` INT")
		if exists $sql_tables{"${course}_set_user"};
};

> And, for the purposes of development
> (3) If I update my test WeBWorK install from HEAD in the CVS, will it
>    break everything (in particular, database access) at this point?  I've
>    been sending my gateway revisions to HEAD, which suggests that I might
>    want to start with an up-to-date copy before playing with this.

HEAD is pretty stable at the moment, and I encourage you to update. 
You'll have to run wwdb_upgrade to get up-to-date on the database format.

Most of the existing database code is ported over to NewSQL, with the 
exception of the versioning code, which still has some architectural 
issues to work out. It works, it's just not in its final form.
-sam