This is a first attempt at a design for supporting quizzes (see Quiz support), surveys, and similar structured inputs, based soley on replicated objects without the need for a relational database on the backend. This is partly an exercise to see the extent to which the CORK/BRIDGE mechanisms will handle this kind of task. It is also a minimal attempt to support the kinds of applications that we've previously built on top of the perl-based "WAFL" system (e.g., the CCIT and epic database) that was originally created as part of the EI project.
WAFL's (mildly) novel feature was the ability to transparently store and retrieve form elements. A "form" html file described a form for editing an object, and a "template" html file described how the results of the form should be presented. The form results were stored as a set of key-value pairs, loaded into a PERL associative array on demand. Key names were taken from names of form elements and a special FIELD tag was used in the template to specify where values should be inserted.
WAFL also used a piece of application-specific perl code that determined when new data instances should be created and how they should be arranged into indexes. This "feature" does not map particularly well to the BRIDGE server model, and probably provides more flexibility than is initially needed for basic surveys.
The general approach for a first implementation would be to simply allow HTML form elements to be included in a variant of the standard wiki-style text object currently used for regular web pages. On posting, all parameters found in the form would be stored an associated with the user (or, possibly, a user-timestamp pair -- see below). In the future nicer UIs could be written that would keep the user from having to see any actual html code. For example, a variant could support the kind of one question, multiple-choice surveys that are used on many websites (like slashdot).
Issues include:
- While the general scheme of saving all form fields eliminates the need to specify the fields explicitly, there may be cases where it would be useful to mark certain fields as "required". This (along with per-user result storage) would cover much of the functionality that was implemented with custom per-app scripts in WAFL.
- If we model this as a survey/quiz tool (instead of a more general database tool), then we should have options to allow:
- Exactly one submission per user, with no re-editing
- Exactly one submission per user, with re-editing allowed
- Multiple submissions per user
- Exactly one submission per user, but multiple guest submissions. (Limiting guest submissions by IP address is tempting, but firewalls would cause problems. Using cookies to limit might work, except, of course, for shared computers.)
- Security: users should not be able to change, and in some cases, see other's responses. In some circumstances, however, the ability to see other's responses would be appropriate and useful. A possible solution to this would be:
- Use a different replicated object for each user. This has scalability implications, but also provides a way for individual user's responses to be identified.
- Have custom Permissions objects based on configurable settings.
- If multiple responses are allowed per user, store these (distinguished by timestamp) within the user's response object.
- In addition to defining the form in shorthand and html, it will be necessary to let the user define the response to posting, assuming we want some form of feedback on successful submission.
- How will result summaries be accessed and formatted?
|