Facility Usage Project Requirements

Team: Webteam Task list Roles Technology: PmWiki Links Development notes Website: About All recent changes Site map

---

This project was unable to deliver a functional installed system. Consequently this effort has been abandoned.

last updated 2006-07-20

Definition of success

• project delivers an operational system
  • integrated into PmWiki (as a cookbook recipe)
    • released to PmWiki community
• documentation (wiki based) complete, including
  • full installation and configuration details (database, software, development environment, maintenance, testing)
  • continuing/future development/maintenance description
  • testing description
• includes an operational testing framework
• open source (same licence as PmWiki)

Project scope

• tight scope, single objective
• test first development (guidelines)
• open source software
• database design to be reviewed by TTC club member

Environment

• MySQL
• PHP
• PmWiki
• Apache
• Unit testing (SimpleTest, PHP Unit, or Tiny unit)
  • see also PHP unit testing tools, and Power PHP Testing

Functionality

• database that includes facility (eg Ski Lodge or Club Rooms) availability and booking information, and in some configurations can be edited as a wiki page, including both display and hidden fields, and the capability to flag some records and fields for display, fields to include
  • name, contact details, membership status, transport requirements, row hidden flag, age if child
  • members and non members can book (but there are rules of precedence)
  • waiting list if fully booked, create, amend or cancel booking
  • note that clubrooms have several rooms that can be booked
  • authentication, initially kept to minimum, by (say) email address and simple user supplied password (enforce some minimums for password)
• when developing allow for future extensibility to include other types of activities (eg trips, socials)
  • to date, trip type, trip location, contact phone, contact email, item hidden flag for individual contact details
• displays can be either editable, and display only, it is envisaged that editable displays would be processed in situ in a table, for example
  • Usage can be trip based, or calendar based
  • notes
  • management attributes (if any over and above PmWiki supplied features)
• all formatting to be controlled by CSS classes (naming convention data*)
• client side javascript may be used, eg to allow selection of, say, only family trips to be visible
• coding should be to a specified coding standard or guidelines

Usage

• embedded as markup in a wiki page
  • selects from defined markups, date ranges, trip types etc
• configured in config.php (part of PmWiki)
  • defines mark up: database, views, columns, date ranges, sorting (default by date ascending), editable or not (say (:data base=dbname view=dbview editable=yes :)