Eventually, ArsDigita decided that it wanted a more generic events registration system that integrated with the ACS. However, it wished to keep its flexibility of being able to easily create repeating events just the way that it could easily offer repeating lectures based upon the same talk. Therefore, the events module was formed around the concept of activities and events, where events are instances of activities just as lectures are instances of talks. Consequently, rather than restricting administrators to only creating talks, the events module enables people to create activities such as a conference and events such as a conference in Boston, MA from August 17-21, 2000. Thus, the events module kept chatauqua's ability to offer repeated lectures easily and generalized it to activities and events.
In addition to providing means for creating and managing activities and events, the events module also yields tools for processing event registrations, aggregating registration information, and communicating with event registrations. These tools enable Web site operators to efficiently oversee their events.
Key3Media collects registration information for events through both paper and Web applications. Web applications go directly into a database; paper applications are entered into the database by Key3Media employees. Once Key3Media processes an application, it sends a confirmation message to the application's registrant. Online registrants receive an online confirmation, and paper applicants receive a paper confirmation.
Upon completing signups for an event, Key3Media exports all of its registration information into a file -- typically a Microsoft Excel spreadsheet -- and gives the file to another company. This company serves as a "holding tank" for the registration data and eventually passes the records to a third company. This third company may be the Key3Media client running the event or perhaps a company building a Web site for the client's event, and it uses the registration data as it wishes.
Key3Media's solution for handling event registration seems to work fine for collecting information. But, its solution does little to help event planners communicate with registrants, coordinate registrants, and aggregate information about registrants. Key3Media cannot inform a client for what other of the client's events a person has registered. Key3Media cannot help registrants collaborate and communicate. Key3Media cannot offer a centralized, unified, and integrated interface to event management. The events module, by focusing on event planners, does offer all these features in addition to facilitating easy online event-registration.
One significant reason for choosing Key3Media is that it will process both paper and electronic registrations. Because the events module is a Web-based application, it cannot intrinsically handle paper applications. However, event administrators may still take advantage of the planning and organizing capabilities of the events module while contracting out registration-handling to a company like Key3Media.
Evite.com focuses on helping users to plan events for which they would like to invite guests. It does this by offering a simple interface for individuals to:
Evite supports repeating events as well as the distinction between activities and events. For example, a user can create invitations for a "Birthday" event and have this Birthday event repeat every year. Birthdays, then, are like activities in the events module, and the annual Birthday parties are like events within the events module. Evite.com, though, does not support creating arbitrary activities like the events module.
Evite helps users handle registrations by allowing users to setup lists of guests to invite to their events. Once a user has setup a guest list for an event, Evite sends e-mail to each person on the user's guest list, notifying him that he has been invited to an event. Evite also allows these invitees to RSVP so that users may see who is coming to their events. Evite lacks, however, a number of the aggregation and advanced registration-handling functions of the events module. Evite also does not let users create events for which arbitrary users can register -- event registrants must first be invited.
Communicating with invitees through Evite takes place through Evite's address book features. Users may store email contacts and create groups of contacts within their address book. Then, they can send e-mail to individual e-mail addresses or to groups of e-mail addresses. This functionality seems fairly limited as it does not provide much support for communicating within the context of an event. For example, users cannot ask to e-mail "all the people who attended these three events" -- as they could within the events module.
If Evite offers limited communications capabilities, it supports even fewer community-building options. Unlike the events module, which supports a host of community capabilities through other ACS modules, Evite merely lets invitees see who else is coming to a particular event.
Evite.com and other event planning sites on the Internet are optimized to help individuals plan social events like a Memorial Day barbeque. The events module was designed to handle enterprise event planning and registration -- and is consequently much more powerful than a site like Evite.com. People may still use the events module, though, to implement something like Evite.com; its data model and Web pages intrinsically support virtually all of the functionality of Evite.
The event module's interface involves creating separate activities, events, and venues in order to preserve the flexibility of offering repeating events. But, this process is overly cumbersome for people who just want to offer a one-time event. A more efficient solution would be to simply provide the event creator with one simple form asking for all the details about an event. This solution would not, though, readily facilitate repeating events.
create table events_activities (
activity_id integer primary key,
-- activities are owned by user groups
group_id integer references user_groups,
creator_id integer not null references users,
short_name varchar(100) not null,
default_price number default 0 not null,
currency char(3) default 'USD',
description clob,
-- Is this activity occurring? If not, we can't assign
-- any new events to it.
available_p char(1) default 't' check (available_p in ('t', 'f')),
deleted_p char(1) default 'f' check (deleted_p in ('t', 'f')),
detail_url varchar(256), -- URL for more details
default_contact_user_id integer references users
);
create table events_events (
event_id integer not null primary key,
activity_id integer not null references events_activities,
venue_id integer not null references events_venues,
-- the user group that is created for this event's registrants
group_id integer not null references user_groups,
creator_id integer not null references users,
-- HTML to be displayed after a successful order.
display_after varchar(4000),
-- Date and time.
start_time date not null,
end_time date not null,
reg_deadline date not null,
-- An event may have been cancelled.
available_p char(1) default 't' check (available_p in ('t', 'f')),
deleted_p char(1) default 'f' check (deleted_p in ('t', 'f')),
max_people integer,
-- can someone cancel his registration?
reg_cancellable_p char(1) default 't' check (reg_cancellable_p in ('t', 'f')),
-- does a registration need approval to become finalized?
reg_needs_approval_p char(1) default 'f' check (reg_needs_approval_p in ('t', 'f')),
-- notes for doing av setup
av_note clob,
-- notes for catering
refreshments_note clob,
-- extra info about this event
additional_note clob,
-- besides the web, is there another way to register?
alternative_reg clob,
check (start_time < end_time),
check (reg_deadline <= start_time)
);
This data model contains, through events_prices, extensions for selling admission to events. The presentation pages, however, do not currently implement this feature. These extensions can tie in with the ecommerce module.
create table events_prices (
price_id integer primary key,
event_id integer not null references events_events,
-- e.g., "Developer", "Student"
description varchar(100) not null,
-- we also store the price here too in case someone doesn't want
-- to use the ecommerce module but still wants to have prices
price number not null,
-- This is for hooking up to ecommerce.
-- Each product is a different price for this event. For example,
-- student price and normal price products for an event.
-- product_id integer references ec_products,
-- prices may be different for early, normal, late, on-site
-- admission,
-- depending on the date
expire_date date not null,
available_date date not null
);
The table events_venues retains knowledge about all the different locations in which an event might take place.
create table events_event_fields ( event_id not null references events_events, column_name varchar(30) not null, pretty_name varchar(50) not null, -- something generic and suitable for handing to AOLserver, -- e.g., boolean or text column_type varchar(50) not null, -- something nitty gritty and Oracle-specific, e.g., -- char(1) instead of boolean -- things like "not null" column_actual_type varchar(100) not null, column_extra varchar(100), -- Sort key for display of columns. sort_key integer not null );
create table events_event_organizer_roles (
role_id integer
constraint evnt_ev_org_roles_role_id_pk
primary key,
event_id integer
constraint evnt_ev_org_roles_event_id_fk
references events_events
constraint evnt_ev_org_roles_event_id_nn
not null,
role varchar(200)
constraint evnt_ev_org_roles_role_nn
not null,
responsibilities clob,
-- is this a role that we want event registrants to see?
public_role_p char(1) default 'f'
constraint evnt_ev_roles_public_role_p
check (public_role_p in ('t', 'f'))
);
create table events_organizers_map (
user_id constraint evnt_org_map_user_id_nn
not null
constraint evnt_org_map_user_id_fk
references users,
role_id integer
constraint evnt_org_map_role_id_nn
not null
constraint evnt_org_map_role_id_fk
references events_event_organizer_roles,
constraint events_org_map_pk primary key (user_id, role_id)
);
The events module organizes registrations in the following way: a registration represents a person who has expressed interest in attending the event. There is one registration for each person who wants to attend. Registrations can have different states. For example, a registration may be wait-listed because there are already too many registrations for a particular event. Or, a registration may be canceled.
An order is a set of registrations. Typically, when a person registers himself for an event, he will create one order containing his single registration. But, there may be an individual who wishes to register multiple people at once. In that case, the individual would make one order containing multiple registrations. Thus, this data model allows people to make multiple registrations. The Web pages do not yet implement this feature, though.
create table events_orders (
order_id integer not null primary key,
-- ec_order_id integer references ec_orders,
-- the person who made the order
user_id integer not null references users,
paid_p char(1) default null check (paid_p in ('t', 'f', null)),
payment_method varchar(50),
confirmed_date date,
price_charged number,
-- the date this registration was refunded, if it was refunded
refunded_date date,
price_refunded number,
ip_address varchar(50) not null
);
create table events_registrations(
-- Goes into table at confirmation time:
reg_id integer not null primary key,
order_id integer not null references events_orders,
price_id integer not null references events_prices,
-- the person registered for this reg_id (may not be the person
-- who made the order)
user_id integer not null references users,
-- reg_states: pending, shipped, canceled, waiting
--pending: waiting for approval
--shipped: registration all set
--canceled: registration canceled
--waiting: registration is wait-listed
reg_state varchar(50) not null check (reg_state in ('pending', 'shipped', 'canceled', 'waiting')),
-- when the registration was made
reg_date date,
-- when the registration was shipped
shipped_date date,
org varchar(4000),
title_at_org varchar(4000),
attending_reason clob,
where_heard varchar(4000),
-- does this person need a hotel?
need_hotel_p char(1) default 'f' check (need_hotel_p in ('t', 'f')),
-- does this person need a rental car?
need_car_p char(1) default 'f' check (need_car_p in ('t', 'f')),
-- does this person need airfare?
need_plane_p char(1) default 'f' check (need_plane_p in ('t', 'f')),
comments clob
);
users_contact
table, as well as any custom information the event collected from him.
If the user is automatically approved upon registration, he is added to
the event's user group.
delete_user_group(v_group_id IN integer): This procedure
deletes a user group. It was intended as a helper procedure for
events_delete_event.
events_delete_event(v_event_id IN integer): This procedure
deletes an event, along with the event's registrations as well as user
group.
events_user_admin_p: returns 1 if current user is an events
administrator.
events_event_name {event_id}: Returns the event's name.
Returns an empty string if event_id is not valid
events_group_add_user {event_id user_id}: Add's user_id to
the user group of event_id's event. Returns 1 if successful, else
returns 0.
events_group_create {name date location}: Given an event's
name, date, and location, creates a user_group for that event and
returns the new group's group_id. Returns 0 if an error occurs
events_pretty_venue {venue_id}: returns a pretty location
based upon a venue_id. If the venue_id is invalid, returns an empty
string
events_pretty_venue_name {venue_id}: returns a
pretty location and that location's name based upon a venue_id. If the
venue_id is invalid, returns an empty string
events_state_widget {{default ""} {size_subtag "1"} {sel_name
"state"}}: returns a select box of U.S. States. default is the
default state to select. size_subtag is the size of the select box.
sel_name is the form variable name of the states.
events_venues_widget {{default "" } {size_subtag
"size=4"}}: returns a select box of venues. default is the
default venue to select. size_subtag is the size of the select box.
events_pretty_event {event_id}: Returns a pretty
description of the event. Returns an empty string if event_id is not
valid
events_member_groups_widget {user_id {group_id ""}}:
returns a select box of all the user groups to which the user
represented by user_id belongs. If group_id is set, that group is
selected by default
events_user_contributions {user_id purpose}: Returns list
of events for which this user has registered. If purpose is
"site_admin," the events will be linked to their admin pages.
events_new_stuff {since_when only_from_new_users_p
purpose}: returns a list of new event registrations since
since_when and optionally only from new users if only_from_new_users_p
is "t." If purpose is "site_admin," then the registrations will be
linked to admin pages.
One of the links from the main administration page is for managing venues. Venues are locations where events occur. Since an organization or person's events will usually take place within a certain set of venues, the events module provides a means of creating and managing these locations. Then, when an event administrator creates an event, he can easily select an existing venue for his event -- and save himself the work of typing in all the relevant information for that venue again.
Event administrators can also view a single registration and perform actions upon it, like approving it.
Another key area which ArsDigita plans to extend is support for sub-communities. Currently, the events module is not "scoped" -- individual user groups cannot have their own instance of the events module. However, since ArsDigita is in the process of reworking how it implements module scoping, it is waiting to finish the new scoping API before adding this feature to the events module.
Finally, there are some areas in the data model ArsDigita plans to re-write because they are not efficient. Foremost of these areas is how the module handles event custom fields. Currently, the data model is styled after the user group module and creates a new event_n_info table for each event. Ideally, the module would store custom information within the user_group_member_fields/user_group_member_field_map tables. But, these tables do not support enough data types for the events module yet. There are plans, though, to update these user group tables in the near future so that the events module may store information within them for registrants.