websubmit.cgi is a script that permits ODU CS students to submit their assignments via the web, submitting files either from their local machine or from their Unix accounts. Support is provided for launching an automatic grading program after each submission.
It also allows students who have completed an assignment to request access to a posted solution, preventing them from resubmitting once they have seen the solution.
websubmit.cgi is a script that permits ODU CS students to submit their assignments via the web. It is intended as an alternative to our internally developed submit command as well as to the Blackboard and OCCS assignment submission facilities. Unlike those alternatives, websubmit allows students to submit files both from their Unix accounts and from whatever PC/console from which they are running their web browser. It also allows for assignments where students must submit multiple files but where the file names are constrained by the instructor.
websubmit also addresses a pet peeve of mine: the submit command and most web-submission utilities rely on students knowing what files they are supposed to turn in and what those files should be named. That may seem a perfectly reasonable expectation, but my experience is that a substantial number of students turn in the wrong sets of files[1] or turn in the files with incorrect names, making grading much more difficult than it needs to be.
By contrast, websubmit.cgi is invoked with an
instructor-supplied assignment description that lists the files to be
turned in, so that students are presented with an explicit list to guide
their submissions. websubmit.cgi is most useful for
assignments where the names of the files to be turned in are determined
ahead of time by the instructor or where, at least, the number of files to
be turned in is relatively small. For assignments that are weakly
structured or that vary by the individual student, have the students
package their project into .zip
or other archive file
formats.
websubmit also provides several optional features:
(optional) invocation of an automatic grading script after each submission and for the (optional) revelation of the instructor's solution when the student is finished with an assignment.
A script can be run automatically after each submission to do grading or notify instructors and graders of the submission.
Solutions can be provided to students, with controls so that, after a student has viewed a solution, (re)submission is no longer allowed.
Limits can be placed on the number of conditions for resubmissions.
(future) Students can view their (most recent) grade report for the assignment.
The instructor prepares, for each assignment, a submission
information file that provides, at a minimum, an assignment title, a
directory where the submissions are to be placed, and a list of file
"filters" (e.g., adt.h
, *.cpp
)
describing what students may submit. The instructor then makes available
to the students a web page containing a link that invokes
websubmit.cgi with the path to the submission
information file supplied as the "asstinfo" parameter. For example: <a
href="https://www.cs.odu.edu/zeil/submit/websubmit.cgi?asstinfo=/home/facultyName/Assignments/asst5.xml"
>Turn in Assignment 5</a>
A student clicking on that link starts at the login page. The student logs in by providing a valid login name and password for a Unix account on the CS Dept network.
After a successful login the student is presented with information about any prior submissions to this assignment and an option of submitting to the assignment or of viewing the instructor's solution.
Let's assume that the student wishes to make a new submission. After clicking on the "Submit" button, the student is presented with a list of files the instructor expects to be turned in for this assignment.
The student can then use the "Browse..." or "Browse Unix..." buttons to select the files to be turned in from, respectively, the student's local computer or from their CS Unix account. When all is ready, the student can press the "Submit Assignment" button to complete the submission.
The student is then presented with a summary of the files turned in, an indication of whether automatic grading is in effect, and a button to close the browser window.
To set up an assignment and allow students to submit their solutions, the instructor creates a submission information file, an XML description of the assignment and of the files to be submitted.
Here is a basic submission information file for the example presented above.
<assignment> <title>CS361: Keeping Your Distance</title> <directory>/home/zeil/courses/cs361Submissions/editd</directory> <file filter="editdist.cpp" required="1"> Your implementation of the editDistance function.</text> </file> <file filter="README.txt"> Notes to the grader, if any. </file> </assignment>
The entire description is wrapped in the assignment element. | |
This gives the title that appears on the various web pages. | |
The directory where student submissions for this assignment will be placed. Usually, each assignment would have a separate directory. | |
One or more file descriptions. Each of these describes a single file to be submitted by the student. A file description has the following components: | |
A filename or filter for the desired filename. These can
include the usual wild card characters (e.g.,
| |
(Optional) Required file marker. If present and if the value of this field is "1", then the file will be marked as "required" in the listing presented to the student. If a student attempts to submit an assignment that is missing one or more required files, the student receives a warning. (Students will be allowed to go ahead and submit anyway, if they wish, because sometimes students do need to submit incomplete work.) If the | |
(Optional) Descriptive text for the file. |
An older release of the websubmit tool used a
less compact format in which the filter, required marker, and
description were provided as nested elements within each file
element.
<assignment> <title>CS361: Keeping Your Distance</title> <directory>/home/zeil/courses/cs361Submissions/editd</directory> <file> <filter>editdist.cpp</filter> <text>Your implementation of the editDistance function.</text> <required>1</required> </file> <file> <filter>README.txt</filter> <text>Notes to the grader, if any.</text> </file> </assignment>
One or more file descriptions. Each of these describes a single file to be submitted by the student. A file description has the following components: | |
A filename or filter for the desired filename. These can
include the usual wild card characters (e.g.,
| |
(Optional) Descriptive text for the file. | |
(Optional) Required file marker. If present and if the value of this field is "1", then the file will be marked as "required" in the listing presented to the student. If a student attempts to submit an assignment that is missing one or more required files, the student receives a warning. (Students will be allowed to go ahead and submit anyway, if they wish, because sometimes students do need to submit incomplete work.) If the |
This older format is still supported to provide backwards compatibility.
When a student submits an assignment, the assignment is saved
using the same directory structure as in the local "submit" command
utility: the student's first submission is placed within a directory
studentLogin.0/
and the time of submission in a
file studentLogin.0.time
. The student's second
submission goes in studentLogin.1/
and
studentLogin.1.time
, and so on.
No provision is made for students' withdrawing old assignment submissions because I don't believe in destroying the "audit trail". Also, no provision is made for limiting submissions to before a "due date", because any such mechanism would inevitably require frequent overriding to accommodate excused late submissions, students working off incomplete grades, etc. This seems to be easier to handle at grading time.
Security of student submissions stems from three features:
The login page, which checks to be sure that the student has a valid CS Dept Unix account. (This is validated by using the login name and password to open an FTP connection on ftp.cs.odu.edu.)
If you don't want your assignments to be accessible to every student in the entire CS dept., you can also supply a "roster file" that lists, one per line, each login name that you wish to grant access to the assignment. This is specified via a \xmlpair{roster} entry for the assignment:
<assignment>
<title>CS361: Keeping Your Distance</title>
<roster>/home/zeil/courses/cs361/Assignments/f10/roster.dat</roster>
...
The websubmit.cgi file itself is hosted on the Dept.'s secure HTTPS server, and runs under group "faculty". As a rule, therefore, all directories and files used by websubmit.cgi, including the submission directory and the submission information file itself, should be readable (and, for directories, executable) by group faculty but not by the world.
The above sections describe the main features of
websubmit
, but there are several options. Instructors
can use these or ignore them, as they choose.
By adding a notify
attribute to the
root <assignment>
element, you can
specify an email address to which a short message will be sent whenever
a student submits. For example,
<assignment notify="cs361@cs.odu.edu">
<title>CS361: Keeping Your Distance</title>
...
</assignment>
In this case, an email message would be sent to (and from) cs361@cs.odu.edu each time a student submits this assignment. A typical message will look like
from: cs361@cs.odu.edu
to: cs361@cs.odu.edu
subject: Submission #1 from jdoe on
editd
jdoe has submitted attempt #1
into home/zeil/cs361Submissions/editd
at Mon Apr 13 00:16:24 1970
websubmit can be used to reveal instructors' solutions to students. Although this is easy enough to do by posting a solution online, dealing with students whom you have given permission to turn work in late or who are working off incomplete grades is something of a problem. How do you reveal a solution to the bulk of the class without revealing it to everyone?
websubmit can serve up solution files from an instructor-designated directory. This directory must be readable and executable by group "faculty", but not by the world. A student who requests access to the solution directory will not be allowed to subsequently submit to that assignment.
To designate a solution directory, add a <solutionDirectory>
element to the
submission information file.
<assignment> <title>CS361: Keeping Your Distance</title> <roster>/home/zeil/courses/cs361/Assignments/f10/roster.dat</roster> <directory>/home/zeil/courses/cs361Submissions/editd</directory> <file filter="editdist.cpp" required="1"> Your implementation of the editDistance function.</text> </file> <file filter="README.txt"> Notes to the grader, if any. </file> <solutionDirectory>/home/zeil/courses/cs361/Solutions/editd</solutionDirectory> <solutionDate>1/1/2001</solutionDate> </assignment>
This specifies the location of the instructor's solution. | |
(Optional) This specifies the first date upon which the solution will be available. |
The solution directory is presented to the students as a
list of files that they can download. If, however, the specified
directory contains an index.html
file, the contents
of that file are shown along with the file list. That HTML file could,
for example, link to other locations or documents i8f desired.
When a students views a solution, a
"marker" is added in the assignment submission directory in the form of
a file named studentLogin.viewed-solution
. This
marker is checked before a student is allowed to submit, and if it is
present the student will not be permitted to submit the assignment. If,
for some reason, you want to permit them to submit anyway, you will need
to manually delete that file.
websubmit can be used to display grade reports to students. This facility is designed to be compatible with the reports prepared by my automatic grader, but the actual report files may be text, HTML, or PDF files, one per student per assignment, so these can actually come from anywhere - there's not a whole lot of flexibility in the directory structure, though.
To provide this facility, add a <gradesDirectory>
element to the submission
information file.
<assignment notify="cs361@cs.odu.edu">
<title>CS361: Keeping Your Distance</title>
<roster>/home/zeil/courses/cs361/Assignments/f10/roster.dat</roster>
<directory>/home/zeil/courses/cs361Submissions/editd</directory>
<gradesDirectory>/home/zeil/courses/cs361Grades/editd</gradesDirectory>
<file filter="editdist.cpp" required="1">
Your implementation of the editDistance function.</text>
</file>
<file filter="README.txt">
Notes to the grader, if any.
</file>
<solutionDirectory>/home/zeil/courses/cs361/Solutions/editd</solutionDirectory>
<solutionDate>1/1/2001</solutionDate>
</assignment>
There are two distinct arrangements that are supported for the grades files:
Within the specified grades directory, create a separate
directory for each student. The directory names should match the
students' login names. Within each student's directory, place a
file named gradeReport.txt
,
gradeReport.html,
or
gradeReport.pdf
Or, within the specified grades directory, place one file
for each student, named with the student's login name:
,
loginName
.txt
or
loginName
.html,loginName
.pdf
Future releases of websubmit may offer some more flexibility on this arrangement.
If a gradesDirectory
has been
specified, a student who logs into the assignment submissions page will
be informed whether a grade has been posted and, if it has, the date of
the posting (the modification date of the grade file). The student will
be given an option (along with the options of submitting and/or viewing
the solution) of viewing that grade report.
As mentioned earlier, students will be blocked from submitting if they have already viewed the assignment solution. There are other ways to restrict students' submissions.
By adding a submissionLimit
attribute
to the root <assignment>
element, you
can specify a maximum number of attempts each student can make. For
example:
<assignment notify="cs361@cs.odu.edu" submissionLimit="3"> <title>CS361: Keeping Your Distance</title> ... </assignment>
This says that students will be allowed to submit a total of 3
times. If no limit is given, then students are permitted to resubmit an
arbitrary number times. If you wish entirely prohibit resubmissions,
therefore, give a submissionLimit
of
1.
This limit is implemented by checking the submissions directory to see how many copies of the assignment have been submitted by the logged-in student. If you wish to override this limit for a particular student (without raising the limit for everyone), you would need to manually remove that student's most recent submission from the submissions directory.
If a grades directory has been
specified, then submission can also be blocked by the presence of an
arbitrary file in the grades directory. Add an attribute block
that names the file to be checked for. If
that file exists in a student's grade directory, then that student will
be blocked from submitting again. For example,
<assignment notify="cs361@cs.odu.edu" submissionLimit="3" block="gradeReport.txt"> <title>CS361: Keeping Your Distance</title> ... </assignment>
This says that students can submit up to 3 times, but that once the assignment has been graded (a gradeReport.txt file exists) then students will be blocked from further submissions (even if they have not used up all three attempts).
Finally, websubmit can invoke a designated
program or script each time an assignment is made. The intention is for
that program to trigger automatic
grading of the assignment. The program to be invoked is
specified via a <grader>
element.
<assignment>
<title>CS361: Keeping Your Distance</title>
<roster>/home/zeil/courses/cs361/Assignments/f10/roster.dat</roster>
<directory>/home/zeil/courses/cs361Submissions/editd</directory>
<file>
<filter>editdist.cpp</filter>
<text>Your implementation of the editDistance function.</text>
<required>1</required>
</file>
<file>
<filter>README.txt</filter>
<text>Notes to the grader, if any.</text>
</file>
<solutionDirectory>/home/zeil/courses/cs361/Solutions/editd</solutionDirectory>
<solutionDate>7/31/2010</solutionDate>
<grader>/home/zeil/bin/requestGrading.pl /home/zeil/courses/cs361/Build/Assignments/sum10/distance/distance.pl</grader>
</assignment>
The text of the <grader>
element
will be passed to the shell for execution, with two additional command
arguments appended:
the student's login name, and
the directory within which the submitted files have been placed
This script could do grading (the example shown queues up the assignment submissions for handling by my autograder program) or might do something simpler such as send an email to the instructor or graders informing them of the submission.
For security reasons, the command named in this element must be executable by group faculty but not executable by the world.
[1] At least once a semester, someone would manage to submit their entire home directory and all of its subdirectories!