|
This document outlines the Web Marking system.
The webmark service is an Apache/PHP web service which calls on LaTeX to generate PDF replicas of 'legacy' marking forms, eliminating much of the duplication of information required to mark (currently) an MSc or UG4 Dissertation/Project.
The service defines a specifically configured Apache server, featuring indirect Kerberos authentication. On this runs a set of PHP scripts which perform the bulk of the work of the service.
The webmark website consists of a number of web 'form groups', each of which share configuration for a number of forms. Each form generates one or more PDF paper versions of the typed data. These PDFs are created by filling predesigned LaTeX templates which match the forms required by School and/or College to mark a piece of work. A PHP script calls LaTeX, generates a PDF which allows the user to save, print or optionally (if authenticated) submit to an ITO storage area.
On Fedora Core 5 servers, authentication is currently carried out using the DICE Apache x509/kx509 functionality, utilising the user's Kerberos credentials directly from their DICE PC or through the Informatics Authportal. On FC6 and SL5 this functionality is provided by Cosign. From the authentication mechanism, access rights could be subsequently derived from the user's 'roles', as given by LDAP.
Using webmark is a three-stage process. Select a specific form to be partially auto-completed from the index page, or simply choose to write a blank form. Once the form has been filled in, clicking preview will produce a downloadable PDF for the user to review the formatted form input. Clicking submit will generate another PDF and, if user permissions allow, send a copy of this to the specified storage location. If submission was successful, the user is notified by a success message, and an email receipt of their submission.
The service was designed to offer no other significant functionality; specifically it was designed to operate statelessly, not relying on any session data. Each of the PHP scripts should have the ability to operate independently of one another. As such, it offers no tracking or dependency checking.
In the first instance, the service is defined, and can be reconfigured, by the following:
webmark/data/forms/.webmark/data/forms/formtype/config.iniBy default, the service expects to be the primary to have the machine's hostname as its main virtual host. To define a service as 'the' webmark service, simply point the appropriate DNS alias at the machine, then define WEBMARK_HOSTNAME to be webmark (or appropriate alias).
Point 1 above would be expected in the normal operation of the server, and are detailed in Installation/Disaster recovery below, and in the header file itself. Points 2 & 3 would be expected in the course of commissioning a new form type, or changing the behaviour of a specific form.
Point 3 in particular might refer to changes to the auto-completed data which is used by the prefilled forms. This file might require modification if the project databases change in structure, or have to be retrieved from another source. The config.ini file defines separate queries and database connection innormation for each form group, kept deliberately separate to aid in future modification. Simply edit the variable which contains the query string, following the same output pattern as is already defined.
The TeX templates (point 2 above) are processed in the following manner:
\providecommand{\fieldname}{Field Value}.pdflatex before being presented to the user as a finished form. The input is filtered such that it should not be possible to create an erroneous LaTeX document, so any errors are handled in a generic manner, requesting the user contact support.Editing the output is simply a matter of adjusting the TeX templates to suit. Editing the input is a matter of adjusting the form html. POST variables are translated (after security filtering) directly to LaTeX commands.
A sample config.ini file is provided which should give enough detail to create new forms as required.
Webmark is almost completely stateless, and so requires no user data to be restored as such. Installation is relatively straightforward:
$ svn checkout svn checkout svn+ssh://svn/disk/svn/webmark/branches/apache /disk/webmark/For FC6 / SL5 / apacheconf platforms:
$ svn checkout svn checkout svn+ssh://svn/disk/svn/webmark/branches/apacheconf /disk/webmark/Note that this can be anywhere secure; it will not be holding long-term data unless you set it as the submit location (a very bad idea).
WEBMARK_SERVERROOT definitions to the actual location of /disk/webmark above.WEBMARK_DOCROOT and WEBMARK_DATAROOT definitions to /disk/webmark/html and /disk/webmark/data subdirectories above, or as appropriate. You should then run the setup script in the root checkout directory.#define WEBMARK_HOST machinenameor
#define WEBMARK_FULLHOST machinename.inf.ed.ac.uk
#define WEBMARK_DOCROOT [webmark base path]/html #define WEBMARK_DATAROOT [webmark base path]/data #define WEBMARK_SUBMIT [directory to accept submissions] #define WEBMARK_YEAR [academic year-beginning, e.g. 2008](see the webmark header for full details)
#include <dice/options/webmark-server.h> to the profile, somewhere below the WEBMARK_ definitions. You should of course copy any relevant configuration from the old profile.updaterpms run file configure x509 configure cosign configure apacheconf configure apacheconf start
|
Please contact us with any
comments or corrections.
Unless explicitly stated otherwise, all material is copyright The University of Edinburgh |
|