Demo Light & Shadow Competition Pre-Registration

Technical Information

This page details some elements of the Camera Club pre-Registration web application. For user instructions visit the help page. In short, this application is meant to make registering images for the camera club’s monthly competition easier. Participation is optional and those who either can’t or won’t do it are able to continue registering manually.

This application uses the following technologies:

Quick Jumps

Demo Information
The Data Model
Output
Forms

This is a Demo

You are looking at a demo version of the application. It runs the same code base as the actual application against a test/demo database. There are some differences from the production application:

The idea is to let you inspect and try out this application without worrying about damaging the data or annoying the owners. Note: While it is likely that you are the only one running this demo at this time, it is not guaranteed. If you see updates happening that are not yours, please be kind. Email me if you see something you do not understand. I am always happy to explain.

Don’t hesitate to try things out. If you notice errors of any type, please let me know!

You can access the demo at any time – create your own user id by going through the email verification process or log in as one of the three pre-defined users. These three users are as follows:

UserAdmin RightsCompetition Rights
demo@can-do-productions.comAllAll
viewer@can-do-productions.comViewView/Print
user@can-do-productions.comNoneNone

All users can enter and modify their own images for competition and print their own image labels/slips.

The password for all three pre-defined users is can-do-demo.

NOTE: It looks like you either have JavaScript turned off or you have a browser I haven’t certified for the Ajax version of the entry form. Everything else will work; JavaScript is not required to for the site. However, you will not be able to use the Ajax entry mode.

[top]

The Data Model

There are three types of entities we deal with: Users, Competitions, and Entries. There is a MySQL table for each of these entities, and an additional table used during email verification for new users.

The relationship between these entities is simple: Users enter Entries in Competitions. Each user may enter up to a number (configurable in the competition table) of entries per medium/class in each competition.

Users

This is the SQL definition for the user table:

CREATE TABLE user (
  id int(6) NOT NULL default '0',
  name varchar(80) NOT NULL default '',
  email varchar(80) NOT NULL default '',
  status enum('new','verified','approved','admin','adminview','denied') NOT NULL default 'new',
  password varchar(15) NOT NULL default '',
  modtime datetime NOT NULL default '0000-00-00 00:00:00',
  pagePermissions set('competitions','competitionsDel','competitionsMod') default NULL,
  displayPrints enum('Y','N') NOT NULL default 'Y',
  PRIMARY KEY  (id),
  UNIQUE KEY email (email)
);

Status starts out as new and is automatically set to verified when the user verifies his email address. That status allows the user to participate, and for most users this is as far as it gets. Status of 'admin' allows access to the user administration page where one can add, modify, or delete users. Approved status does not add any additional privilege, but it can be used to indicate that an administrator has noticed and approved the user.

PagePermissions give specific privileges. At this time we have three that deal with access to the competitions page. The first allows simple read-only access; the second allows deleting competitions, and the third allows adding and modifying competitions. PagePermissions are simple to extend if we ever need more permissions for the application.

Competitions

SQL for competition table:

CREATE TABLE competition (
  id int(6) NOT NULL auto_increment,
  name varchar(30) NOT NULL default '',
  competitionDate date NOT NULL default '0000-00-00',
  openDate date NOT NULL default '0000-00-00',
  closeDate date NOT NULL default '0000-00-00',
  closeTime time NOT NULL default '15:00:00',
  judge varchar(50) default NULL,
  media set('slide','print') NOT NULL default '',
  slideClasses set('Color-Reg','Color-Adv','Travel','PJ','Nature','Creative') default NULL,
  printClasses set('Monochrome','Color-Reg','Color-Adv','PJ','Nature','Creative','Commercial') default NULL,
  slideMaxEntries smallint(3) NOT NULL default '0',
  printMaxEntries smallint(3) NOT NULL default '0',
  PRIMARY KEY  (id),
  KEY competitionDate (competitionDate)
);

The application allows easy addition of media types. For example, if the club were to add a “digital” competition, all we would have to do is to add digital to the media column and add two new colums: digitalClasses and digitalMaxEntries. The code will notice the new table structure and allow competitions to include the new medium.

Entries

An row in the entry table represents a competition entry (currently a print or a slide.) Here is the table structure:

CREATE TABLE entry (
  id int(6) NOT NULL auto_increment,
  userId int(6) NOT NULL default '0',
  competitionId int(6) NOT NULL default '0',
  medium varchar(30) NOT NULL default '',
  class varchar(30) NOT NULL default '',
  title varchar(250) NOT NULL default '',
  printed enum('Y','N') default 'N',
  PRIMARY KEY  (id),
  KEY userId (userId,competitionId)
);

The printed column tracks whether the image owner has printed a label for it yet. If it is "N" then the corresponding checkbox on the label printing page is checked by default. The rest of the columns are fairly obvious – they detail the image’s medium, class, and title and tie it in to a competition and a user.

[top]

The Output

The whole point of this application is to produce pre-filled competition sheets for the print chair to take to competition. There is a minimum of one page per medium/class combination. Each medium/class combination also has empty slots for manual entry by those who did not use the web application.

Club members must affix a label to the back of each print and submit an entry slip with each slide. This application allows each user to print these labels/slips. This function was not the driving force behind this application, but since it has all the information available, it offers a nice incentive for club members to participate. The labels can be printed for plain paper or Avery 5163 or Avery 5164 sticky shipping labels.

All paper output is in Adobe PDF format. The user has an option to open the PDF in a new browser window or download it as a file. He or she can then print them on any standard printer.

[top]

Entering Data in Forms

The Entries Page

The main page of the site (index.php) is the one where most users will spend most of their time. This is the page where they enter the title of each image they are entering in the competition. If there is more than one open competiton they must pick from a list. If there is only one, the page goes straight to the entry form.

This form is basically a set of text input controls, separated by medium/class. There are the maximum number of allowed input boxes per medium/class. Rules for the real club specify two entries per medium/class at this time. The application allows the competition chairs set the number of entries per class.

The entry form lends itself very nicely to asynchronous updates. The user picks an update mode using a set of two radio buttons at the top of the page. Choosing one of the modes modifies the user instructions appropriately, and either hides or shows the Submit and Cancel buttons at the bottom. Users who have JavaScript disabled or are not using one of the certified browsers do not see the mode choice radio buttons and the entry form is always in the tranditional Submit/Cancel mode.

NOTE: It looks like you either have JavaScript turned off or you have a browser I haven’t certified for the Ajax version of the entry form. Everything else will work; JavaScript is not required to for the site. However, you will not be able to use the Ajax entry mode.

The current list of browsers on the certified list:

If you can help me move browsers on or off this list, email me. I have tested all the above except the Linux ones: Konquerer and Linux FireFox. I am confident that Linux FireFox is compatible, but less secure about Konquerer.

Async Entry Flow

The entry form hooks change event listeners to each of the text input controls. When the event listener is called:

  1. Create and post an XmlHttpRequest
  2. Indicate the state for the user by displaying an ellipsis symbol to the right of the text box
  3. The server code gets the Ajax request, validates and processes it (update, insert, or delete an entry row)
  4. The server formats and sends an XML response
  5. If the browser does not receive a response within ¼ of a second, disable the text box, keeping the user from trying again too soon
  6. When the response arrives, display the status (OK or ERR) in place of the ellipsis
  7. If the status is an error, display the text associated with the status (comes from the server as part of the response)
  8. If the control had been disabled, re-enable it

The form also hooks the focus event for each text box. When this fires it clears any old status indication for that control, as the user is likely making a new update (perhaps correcting a typo.)

Most of the time, the server responds fairly quickly, but if there is a delay the user can continue making additional changes on the form. Multiple requests can be outstanding at one time.

[top]

Entries Print Labels Help Tech Info