design

Event Calendar是一个在线事件日程

the very least they contain opening and closing HTML tags).  Between the
header and footer is a single rowed table (left and right columns) whose
left column contains a bunch of modular boxes that perform different
actions on the calendar.  The right column contains the output of
whichever box has been used last.

The source is only slightly more complicated.  First, a few variables are
set, such as the current session and whether the remote host is within the
Simon's Rock domain.  An array of "boxes" (discussed soon) is initialized
for the left side, and if one requires the use of HTTP headers
(setcookie), the the box is called to perform its action.  The header is
included, and the inner table built.  For the first column, the page loops
through the array of boxes and has them output their box.  The background
colors of these boxes are controlled by the main page, with the
alternation achieved through an incrementing variable.  For the right
column, the currently selected box outputs its results.

The main page also tests whether cookies are enabled, since cookies are
essential for storing a session key.  The page sets a test cookie and
passes another variable along to the next page in the URL.  When this
variable from the URL is set, the main page checks to see if the cookie is
also set.  A global cookies_enabled variable is set to 1 or 0 for other
objects to test.

BOXES
=====
To simplify the main page's code, an abstract "box" class was created.  A
subclass could then be created to handle the specifics of each action,
while still allowing the main page to simply call the same functions for
each one.

The abstract contains several variables, some set as constants in the code
and others set during initialization.  Among the constants are whether or
not the box requires the use of headers, whether help is available for the
box, and what the name of the help topic should be (if there is one).
These are set in the code because they are directly affected by what is
coded in the file.

Those variables set during initialization are: a URL to use as the action
in forms that are output, the name of a global variable that holds the
current session, and whether a login is required.  The are set during
initialization because they may be affected by code outside the class.

The box class also defines a few generic functions that are used in
performing the various required tasks.  Not all of them need to be
overridden in the inherited classes, especially is they won't be used by
the subclass.

The outputPDeniedNotice spits out a generic error saying "You're not
allowed to do this."  outputBox will generate the HTML for the module in
the left column of the page, sometimes as simple as a single link.
parseBox and outputResults will perform the box's action.  parseBox should
only be called if headers are required, since it only parses input and
sets necessary cookies, etc.  outputResults is what actually outputs stuff
on the right half of the page.  outputHelp can just be a chunk of HTML
wrapped in a function.  This is called to display help for the box's
action if there is any.  verifyPermissions will check to see if the
current session is allowed to use the box (or just return 1 if permissions
don't matter).


BOX - CALENDAR
==============
The calendar box displays the little month view at the top of the left
column.  Users can browse through the calendar by date using this box,
viewing a day or week at a time, or a certain day of the week through the
entire month.  The calendar box makes extensive use of a global variable
"timestamp", which is usually passed in the URL.  (The main page will
actually put it in the action URL that it passes to boxes.)

When outputting the box, the calendar box looks at the set timestamp, or
defaults to the current time if there isn't one, and generates a calendar
for the given month and outputs it in an HTML table.  The numbers and
headers are links that set the timestamp and select a view for the
results.  Links are also included to cycle through the months, as well as
a toggle to view/hide unapproved events.

Viewing unapproved events makes use of a cookie so the option persists
through HTTP connections, thus parseBox is used to set or delete the
cookie before anything is output.  The text-only result view also makes
use of parseBox to output the event text and exit PHP without finishing
execution.

Otherwise, assuming the calendar box is active, SQL will be built to find
the appropriate list of events, and the box will run through the list and
have the events output their details.  This is done using an index table
which keeps a list of event IDs for the events that occur on each day.  To
check for events on that day, a search is done for the timestamp of
midnight that morning, which is where all the events for that day are
listed in the index.  When the calendar box loads, it fetches the index
for the entire month.  While outputting the calendar it checks this index
for the presence of events so it can highlight days which contain events
in green.  When outputting week and day views, the box also uses this
index so it may simply search for event IDs instead of building a more
complicated query.


BOX - SEARCH
============
The search box is pretty self explanatory, but unfortunately the code
couldn't be simplified as much as I'd like.  The search box consists of a
single text field for a basic search, and a link to the advanced search
form.

The basic search will search for events with the key string in the title
or description.  The advanced search lists all fields with a text box for
values, or a list of checkboxes if there are multiple choices.  Search
results must match at least one value in each field where a value is
selected.

In both cases, results are displayed as a simple list, ordered by date, of
events.  The event details can be viewed, using the event class for
outputting values.


BOX - LOGIN
===========
The login box is a little tricky.  First, there's an extra variable,
declared globally, stating whether logins require SSL (generally a Good
Thing).  If so, and the global variable SSL_PROTOCOL_VERSION is not set,
the box will output a notice stating that you must switch to SSL.  Next,
it checks a global variable set by the main page to see if cookies are
enabled.  If not, the box outputs a notice that cookies must be enabled to
log in. Otherwise, if you are not logged in, the box outputs a form in
which you can log in.  When you've logged in, the box contains options to
display session information, logout, or renew the session.  Most of the
actual functionality is done through the session class and the 
verifyPassword function, both discussed above.


BOX - SUBMIT
============
The submit box could not be easier.  The box itself is simply a link to
the submit form.  The form creates an empty event and tells it to output
an edittable form.  Through the use of multiple submit buttons, the event
can then be submitted (a new event is created from globals and saved) or
previewed (the event from globals outputs its detail view and then its
edittable view).  Almost everything is handled by the event class,
including an e-mail notification to any administrators for the event's
location.


BOX - APPROVE
=============
The approve box, as is the case with most of the components, works pretty
simply.  When asked to output a form with a list of events to approve, it
grabs permissions from the current session and goes through each location
looking for approve access.  The approve box searches for events that have
no approver ID and are in the allowed locations.  It lists them, along
with their details, and a couple options (approve, reject, ignore).  When
the form is submitted, the appropriate actions are taken. Reject has a
text field for the rejecter to include the reason for rejection.  Approval
and rejection are both handled by the event class.

With the addition of submitted modifications, the approve box also looks
for events which contain a modify_id and are in locations for which the
user is allowed to *modify* events.  Using the modify bits allows users to
be allowed only to approve events and not get around lack of modification
privileges by approving their own submitted modification.


BOX - MODIFY
============
The modification box is based heavily on the submit box, using the event
class to output an edittable form of the event.  The event class also
saves the changes, using an UPDATE statement instead of INSERT as it would
for the submit box.  If the user is not allowed to modify the event, a new
event is submitted with a modify_id to mark it as a submitted
modification.


BOX - DELETE
============
The delete box works similarly to the approve box, in that it first looks
at permissions and then searches for events.  The main difference,
however, is that there is a cutoff for the number of events listed in the
form (since there will probably be many more deleteable events than those
awaiting approval).  After the cutoff, a link is displayed that will cause
the box to search again with a minimum event ID added to the query.
Beneath each listed event are the options to delete or ignore the event.
If any events are deleted, the submit button will bring up a confirmation
form that lists those events to be deleted, each with a confirmation
option.  A function is called from the event class to delete each event.


BOX - HELP
==========
When the help box is called upon to display some help, it goes through the
main page's array of boxes and checks to see which have help available.
It then lists the topics of those available boxes, along with some help
text beneath.  Which box's help text is displayed is determined by the
topic chosen, but defaults to the help box's help text.