Last time I tried to integrate a calendar into Moodle I made the mistake to bundle everything up as a module (the event module). Martin did not like this because of course the calendar table should be something central to Moodle and should not belong to a particular module. So I would like to try again. Martin, please let me know whether I am coming closer to something that can become standard. Here is my proposal:
1) There should be a new table in Moodle to hold all timed events. The structure of this table will become more complicated as more modules start to produce more types of timed events but for a start I think the following fields will be sufficient:
CREATE TABLE `mdl_calendar` (
`id` int(10) NOT NULL auto_increment,
`module` int(10) NOT NULL default '0',
`instance` int(10) NOT NULL default '0',
`course` int(10) NOT NULL default '1',
`name` varchar(255) NOT NULL default '',
`timestart` int(10) NOT NULL default '0',
`duration` int(10) NOT NULL default '0',
`externalid` int(10) NOT NULL default '0',
`timemodified` int(10) NOT NULL default '0',
PRIMARY KEY (`id`)
) TYPE=MyISAM COMMENT='for everything with a time associated to it'
The fields 'module' and 'instance' together hold the information about what module instance created the event. The field 'course' is then really redundant but it is convenient and appears to be Moodle practice to have this information exlicitly. The fields 'name', 'description', 'timestart' and 'duration' are self-explanatory. The only non-obvious field is 'externalid'. This field is filled in when the event is published in an external calendar (like Webcalendar) and allows Moodle to find the event there when it needs to be changed or deleted.
2) There should be a library calendarlib.php with the following functions:
These should do the obvious, namely add, update or delete an entry in the calendar table. The first two take as argument an object with the same fields as the calendar table. The last one takes as argument the id of an entry in the calendar table.
All modules that wish to modify the calendar table should do it using these three functions rather than by directly manipulating the table. The reason is explained in point 4) below.
3) All parts of Moodle are free to use the information in the events table. For example Martin has been planning to have a mini-display inside MyMoodle on the home page that looked something like this for each course:
- 1 new assignment posted
Coming up soon:
- Assignment "Essay on stuff" due: Thursday, 9th July 2004, 5:00pm
- Quiz "Revision of week 3" closes: Friday, 10th July 2004, 5:00;pm
4) In order to integrate an external calendar like webcalendar the definitions of the functions in calendarlib.php can be changed to also update this external calendar. This part will not be a central component of Moodle. Moodle will come with its standard calendarlib.php which only updates the calendar table. However there will be optional alternative versions of calendarlib.php which perform the integration with external calendars.
This completes my proposal. The beauty is that once the calendar table and the three functions calendar_add_event, calendar_update_event, and calendar_delete_event are part of central Moodle then the updating of the individual modules to make use of the calendar table can be completed without rush by the module's maintainers. So I hope that this proposal does not add too much to Martin's heavy workload.