dominoGuru.com

Your Development & Design Resource

Public Build: Event Calendar

In this post - the first in an ongoing series of Public Build projects - I plan to discuss the first steps when starting a project, followed by additional posts, screencasts, and other publishings specific to this particular build project.

About this Project

A customer of mine was in dire need of a simple events calendar to facilitate their corporate training endeavors. This simple events calendar, which we'll call Events Calendar (or EC for short), will consist of event coordination through the native Lotus Notes client, review and "reservations" via a web browser client (Internet Explorer 6+ in this particular case, but we'll write for everything), and simple integration with a shared mail database and calendar that will handle all of the actual Calendaring & Scheduling work.

This project - at least phase 1 - is due by 12/31/2008, and counts against my project champion's year-end reviews.

Getting Started

You went for the Domino Designer client didn't you?! Tsk tsk tsk -- we're not going to touch the Designer client until we're actually ready to code something. And with (... checking Calendar) less than 3 days until this application needs to go live, the last thing that we need to do is get stuck in the building phase before we've confirmed the functional requirements for our build project.

Those of you who have checked out YellowCast may be familiar with the term Napkin Development. Those of you who haven't (for shame!) or would like a recap, Napkin Development is the simple practice of blueprinting the application outside of the code, through a combination of workflow diagrams, ~pseudocoding, and - when the need arises - jotting something down on a napkin!

This may seem an inconvenience, but consider this:

  1. This allows you to easily confirm that you understand what the customer wants (and that they understand what they're asking of you) -- which greatly decreases scope creep.
  2. ... and since I hate to document things, you can use the majority of the blueprinting as a jumpstart to the documentation of the project!

So, let's start by talking a little bit more about the build project itself:

  • 3 User Types: Event Admin : Attendee : Coordinator
  • 2 Client Types: Lotus Notes : Web Browser
  • An Event Admin will create an event entry in the EC via Lotus Notes, Attendees across the organization will create a reservation entry for a given event via their Web Browser, and the Coordinator will use the reservation data to create emails, and invite the Attendees to a scheduled Meeting through a pre-existing established Group Mail Database.

That's pretty much it for phase 1 on this project. The architecture-minded will immediately consider creating a simple Parent-Child data hierarchy with the Event and Reservation entries respectively, which is exactly what I plan on doing.

For those of you who are more visually-minded (like me), here is a simple architecture diagram of how we'll design EC:

Events Calendar - Architecture Overview

Data

Now that we have a rough idea of what the application will do, as well as the "main players", we're going to deep dive into what each type of NotesDocument in our NotesDatabase will contain from a data perspective.

As we've established, there will be two types of NotesDocuments: Events and Reservations. Each of these NotesDocuments will contain both functional and data storage NotesItems, and we'll take a few moments to outline the ones that we know we'll need now:

Event|event

NotesItem Usage
title Simple 1-line identifier for the event.
description Multi-line descriptive identifier for the event.
date_start Starting Date for the event.
time_start Starting Time for the event.
date_end Ending Date for the event.
time_end Ending Time for the event.
location Location/venue for the event.
categories Optional categorization option for the events.
subject Computed - special NotesItem name used for bookmark mouseover text.

Reservation|reservation

NotesItem Usage
$ref Created automatically, stores the Event NotesDocument UNID.
username Computed, using the user's runtime evaluation of @UserName

And that's really - the Event Admin will create an event NotesDocument, entering in the Title, Description, date and times of the event, it's location, and any categorization they choose. Pretty simple. The reservation is simply a username-stamped Response NotesDocument to the event NotesDocument.

The real work is going to be the visual representation of the events on the web browser client, with the ability to click and create a reservation. That, we'll cover in the next post - where we should be finished with the blueprinting of the application and move onto planning which particular technologies we will employ to deliver our Events Calendar!


About the author: Chris Toohey

Thought Leadership, Web & Mobile Application Development, Solutions Integration, Technical Writing & Mentoring

A published developer and webmaster of dominoGuru.com, Chris Toohey specializes in platform application development, solutions integration, and evangelism of platform capabilities and best practices.



More from dominoGuru.com


dominoGuru.com is powered by IBM Notes Domino XPages & hosted by Prominic.NET

Contact Us

Use our Contact / Feedback form or one of these email addresses:

Creative Commons License

Except where otherwise noted, dominoGuru.com by Chris Toohey is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.