WebSubmit

Steven Zeil

ODU Dept. of Computer Science

August 8, 2010


Table of Contents

1. Abstract
2. Overview
2.1. A Walk-Through of the Assignment Submission Process
2.2. Walkthrough: Viewing Assignment Solutions
3. Setting Up Assignment Submission
3.1. The Basics
3.2. Security
4. Optional Features
4.1. Email Notification of Student Submissions
4.2. Publishing Assignment Solutions
4.3. Displaying Grade Reports
4.4. Restricting Student Submissions
4.5. Running a Command Upon Submission

1. Abstract

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.

2. Overview

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.

2.1. A Walk-Through of the Assignment Submission Process

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.

Figure 1. Login Page

Login Page

Making a Submission

Figure 2. Submit or View Solution?

Submit or View Solution?

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.

Figure 3. Submitting a Solution?

Submitting a 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.

Figure 4. Submission Completed?

Submission Completed?

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.

2.2. Walkthrough: Viewing Assignment Solutions

Instead of submitting an assignment, the student may be offered an option of viewing the instructor's solution and/or viewing their most recent grade report. These are optional features described later.

Figure 5. Viewing a Solution

Viewing a Solution

3. Setting Up Assignment Submission

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.

3.1. The Basics

Here is a basic submission information file for the example presented above.

<assignment> 1
  <title>CS361: Keeping Your Distance</title> 2
  <directory>/home/zeil/courses/cs361Submissions/editd</directory> 3
  <file4 filter="editdist.cpp"5 required="1"6>
     Your implementation of the editDistance function.</text> 7
  </file>
  <file filter="README.txt">
     Notes to the grader, if any.
  </file>
</assignment>

1

The entire description is wrapped in the assignment element.

2

This gives the title that appears on the various web pages.

3

The directory where student submissions for this assignment will be placed. Usually, each assignment would have a separate directory.

4

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:

5

A filename or filter for the desired filename. These can include the usual wild card characters (e.g., *.txt). Students can override these filters to submit files with completely different names, if they have particularly stubborn or suicidal inclinations.

6

(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 required element is missing or contains some other value, the file is marked as optional and no check is made before submission.

7

(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> 1
    <filter>editdist.cpp</filter> 2
    <text>Your implementation of the editDistance function.</text> 3
    <required>1</required> 4
  </file>
  <file> 
    <filter>README.txt</filter>
    <text>Notes to the grader, if any.</text> 
  </file>
</assignment>

1

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:

2

A filename or filter for the desired filename. These can include the usual wild card characters (e.g., *.txt). Students can override these filters to submit files with completely different names, if they have particularly stubborn or suicidal inclinations.

3

(Optional) Descriptive text for the file.

4

(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 required element is missing or contains some other value, the file is marked as optional and no check is made before submission.

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.

3.2. Security

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.

4. Optional Features

The above sections describe the main features of websubmit, but there are several options. Instructors can use these or ignore them, as they choose.

4.1. Email Notification of Student Submissions

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

4.2. Publishing Assignment Solutions

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> 1
  <solutionDate>1/1/2001</solutionDate> 2
</assignment>

1

This specifies the location of the instructor's solution.

2

(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.

4.3. Displaying Grade Reports

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:

  1. 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

  2. Or, within the specified grades directory, place one file for each student, named with the student's login name: loginName.txt, loginName.html, or 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.

4.4. Restricting Student Submissions

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).

4.5. Running a Command Upon Submission

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!