Moodle in English: New attempt at calendar integration

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 '',
`description` text,
`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:

calendar_add_event($event)
calendar_update_event($event)
calendar_delete_event($eventid)

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:

Example course name 101

- 5 new forum posts
- 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.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Thomas Robb - sekmadienis, 2004 sausio 11, 06:28

While the calendar should be 'central' I think that it also should be something which is maintenance-free from the course creator's standpoint. I found the WebCT calendar to be a real bear to maintain since one had to set up dates manually rather than it automatically grabbing relevant data 'on the fly'. Gustav's set-up does appear to address this problem.

Data location

There seem to be two basic approaches to maintaining time data, one, to gather all time-related data together as Gustav proposes here, and the other, for the calendar module to scan specified modules to gather the requisite data.

Right now, it seems that Moodle takes the latter approach for most functions. It probably *would* add to Martin's workload if something fundamental like this were done the other way 'round.

Having almost completed the "hide until" feature for forums, in this instance it would mean that the forum module would have to refer to the calendar table in order to ascertain whether postings should be hidden or not rather than having the data available in the same object as the rest of the forum thread data.

Data structure

Concerning the table structure, I think that it would be preferable to have an 'endtime' rather than having to calculate it from starttime + duration each time. I don't think that there will be much call for a display of duration, but the code will often need to compare the endtime to the current time, for example, the "Coming up soon" display.

Data entry

How would the "Description" be filled in? Supposedly the fields would be filled in when one is installing a new instance of a function. Each function has a description field already. What might be needed, however, is a new "short description" field to display on the calendar itself.

Also, would each function's set-up display have a checkbox for "Show in calendar" which would automatically default to on/off depending on how the instructor had initially set up the course?

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Gustav W Delius - sekmadienis, 2004 sausio 11, 06:49

Thomas, thanks for raising those points:

Data location: I agree with you that currently Moodle does not have any central tables to which the modules are asked to write data. Instead the modules are polled for the information each time Moodle needs it. However this is a very inefficient way of doing things and Martin would like to move away from it. We do want to move towards a central grades table for example. So I think having a central calendar table is the right way to go.

I don't agree with you that it is more work to write the module functions that write to the central calendar table than to write the module functions that reply to the polling. I also don't think Martin would have to be much involved with this beyond giving his o.k. for the general idea. Once he agrees to the central calendar table then lots of volunteers (me included) will write modules that use it.

Data structure: Your suggestion to use 'timeend' rather than 'duration' makes some sense. However arguments could also be found for using 'duration', for example that it is the way one mostly thinks about events. I have no strong opinions about this.

Description field: The idea is that every event should have a short description in the 'name' field and a longer description in the 'description' field. The 'name' should be short enough for in-line display whereas the 'description' can be arbitrarily long. In a calendar for example the 'description' would only show when one hovers of clicks on the 'name'.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - sekmadienis, 2004 sausio 11, 20:06

I'll put my vote in for timeend instead of duration .. my gut feeling is that it will make some comparisons easier, but it's really much of a muchness and easy to convert either way.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration-Multiple times/same instance

Thomas Robb - sekmadienis, 2004 sausio 11, 11:26

For forum discussions, the same instance will probably require multiple dates in the mdl_calendar table:

Start + duration of the posting itself
Start + duration of initial hiding from others
Start + duration of period for ratings

While these multiple records for the same instance could remain unlabelled, I would hope that the mdl_calendar table would provide a clue to the meaning of the date/time via an extra field.

For example, if the date/time info is removed from the mdl_forum table, then it would probably contain three fields, all of which point to different records in the mdl_calendar table:

availabletime
hidetime
assesstime

I would personally prefer an additional "function" field in mdl_calendar that could be filled with 'avail', 'hide' or 'assess', for example. Otherwise, the meaning of these almost-identical records would be rather opaque.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration-Multiple times/same instance

Terri Teacher - sekmadienis, 2004 sausio 11, 18:00

An additional "function" field in the mdl_calendar table might indeed be a good idea. Each module posting events could choose for itself how it wants to use this field.

Do you think this general purpose field should be a text field or an integer field? In principle the values 1,2,3 would do just as well as 'avail', 'hide', 'assess'. Most tables in Moodle use the type smallint for fields that can only take a small number of different values.

Before going into such details (such fields can always be added later when their need arises) I would like to hear from Martin whether the general scheme meets with his approval.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration-Multiple times/same instance

Thomas Robb - sekmadienis, 2004 sausio 11, 18:27

Thanks for the input, but it would be really nice if we knew who was posting this rather than 'demo teacher'!

I tend to like clear values over integers which force you to look somewhere else to find what they really mean. To me, the use of integer values harks back to the "bad 'ol days" when every bit counted. We can now have the luxury of making our values more meaningful. Even a single character for each value would be more meaningful -- though two of the names I chose in my earlier posting start with 'a' which is a bit problematic...

Įvertinimų vidurkis: -

Re: New attempt at calendar integration-Multiple times/same instance

Gustav W Delius - sekmadienis, 2004 sausio 11, 18:33

I hid my identity by mistakes in my last two posts because I forgot to log in as myself again after having a look at the teacher demo course.

You have convinced me that a text field is better than an integer flag. Of course it only makes a difference to people who actually look directly at the database. But being one of these people myself I admit that I have frequently been annoyed by not being able to figure out easily what the integer values in the Moodle tables mean.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - sekmadienis, 2004 sausio 11, 20:04

I'm happy with this ... it's pretty close to what we discussed before.

Yes, putting courseid in there is redundant but for a very small increase in space can save a lot of SQL later.

Those three functions in lib/calendarlib.php would maintain the internal table and then (if an external calendar was setup) would call matching functions in moodle/calendar/PLUGIN/lib.php to do "extra" work, such as simultaneously updating the external calendar.

The other issue apart from the real-time updates are full-data "pumps and dumps"

. For example, if you just added a new external calendar, you'd want all the current Moodle data to be pumped over to it so they became synchronised. Likewise, if someone wants to export their whole personal calendar into a non-networkable system (eg a handheld, or iCal), then they will have to choose to do produce a dump of the whole data in iCalendar format, or XML, or whatever. I guess for these two functions there will be optional functions with standard names in the calendar plugin files. Finally, there might be a need for a hook from cron to allow plugins to do something automatically if they choose.

Even though we have a modules-push-to-core model here (rather than the core-pulls-from-modules model of recent activity, for example) ... we still need to have a core-pulls-from-modules solution for sites that are upgrading.

I'm going to ignore trying to think about backup/restore issues right now.

Overall though, looking good!

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Gustav W Delius - sekmadienis, 2004 sausio 11, 20:53

I am glad you are happy with the proposal. Do you want me to provide the central code or do you want to write it yourself? I think it would be good enough for a start to to create the table and to implement the three functions for adding, updating and deleting events from the calendar database (should these go into datalib.php?).

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - sekmadienis, 2004 sausio 11, 21:37

It's all yours if you want it (should be easy to port your events module) .. I need to finish G_____.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Gustav W Delius - trečiadienis, 2004 sausio 14, 07:18

O.k., here is the structure for Moodle's internal events table that I have finally settled on:

CREATE TABLE prefix_event (
  id int(10) NOT NULL auto_increment,
  module int(10) NOT NULL default '0',
  instance int(10) NOT NULL default '0',
  name varchar(255) NOT NULL default '',
  description text NOT NULL,
  type varchar(20) NOT NULL default '',
  course int(10) NOT NULL default '1',
  timestart int(10) NOT NULL default '0',
  duration 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';

You will notice that I decided to give the nice name "event" to this table because that is in line with Moodle convention where each table is named by what it contains. This means that I can no longer call my module "event" but I thought it was more important that Moodle's central tables have nice names than that modules have nice names.

Another change from what I proposed earlier is that there is no field holding the id number of the corresponding entry in the external calendar. That is because we will now have a calendar plugin architecture that allows any number of external calendars. The external calendars will have to keep this info in their own tables.

The plugin architecture works as proposed by Martin: each external calendar should be dropped into a subdirectory of the cvs:/moodle/calendar/ directory. A subdirectory 'somecalendar' needs to contain at least a file lib.php which defines the functions:

somecalendar_add_event($event)
somecalendar_update_event($event)
somecalendar_delete_event($eventid)

As discussed earlier, events are added to Moodle's events table by calling the functions

add_event($event)
update_event($event)
delete_event($eventid)

which in turn call the corresponding functions of all the calendar plugins. These functions are defined as follows:

/// CALENDAR ////////////////////////////////////////////

function add_event($event) {
/// call this function to add an event to the calendar table
///  and to call any calendar plugins
/// The function returns the id number of the resulting record
/// The object event should include the following:
///     $event->name         Name for the event
///     $event->description  Description of the event (defaults to '')
///     $event->module       ID of module that creates this event
///     $event->instance     Instance of the module that owns this event
///     $event->type         The type info together with the module info could
///                           be used by calendar plugins to decide how to display event
///     $event->timestart    Timestamp for start of event
///     $event->duration     Duration (defaults to zero)

    global $CFG;
    $event->timemodified = time();
    
    if (!$event->id = insert_record("event", $event)) {
        return false;
    }
    
    // call the add_event functions of the calendar plugins
    if ($calendars = get_list_of_plugins('calendar')) {
        foreach ($calendars as $calendar) {
            include_once("$CFG->dirroot/calendar/$calendar/lib.php");
            $calendar_add_event = $calendar.'_add_event';
            if (function_exists($calendar_add_event)) {
                $calendar_add_event($event);
            }
        }
    }
    
    return $event->id;
}


function update_event($event) {
/// call this function to update an event in the calendar table
/// the event will be identified by the id field of the $event object

    global $CFG;
    $event->timemodified = time();
    
    // call the update_event functions of the calendar plugins
    if ($calendars = get_list_of_plugins('calendar')) {
        foreach ($calendars as $calendar) {
            include_once("$CFG->dirroot/calendar/$calendar/lib.php");
            $calendar_update_event = $calendar.'_update_event';
            if (function_exists($calendar_update_event)) {
                $calendar_update_event($event);
            }
        }
    }
    return update_record("event", $event);
}


function delete_event($id) {
/// call this function to delete the event with id $id from calendar table

    global $CFG;
    // call the delete_event functions of the calendar plugins
    if ($calendars = get_list_of_plugins('calendar')) {
        foreach ($calendars as $calendar) {
            include_once("$CFG->dirroot/calendar/$calendar/lib.php");
            $calendar_delete_event = $calendar.'_delete_event';
            if (function_exists($calendar_delete_event)) {
                $calendar_delete_event($id);
            }
        }
    }
    return delete_records("event", 'id', $id);
}

I would like to ask Martin to place these definitions somewhere into cvs:/moodle/lib/moodlelib.php or whereever he thinks suitable. Also the above SQL code to create the table needs to be added to cvs:/moodle/lib/db/mysql.php and cvs:/moodle/lib/db/mysql.sql.

Once the event table is in CVS I will post a webcalendar plugin which simply needs to be dropped into the calendar plugin directory.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - penktadienis, 2004 sausio 16, 23:00

Hello Gustav!

Your work on the calendar integration is of great interest to me, because (in a few words):
I 'm involved in a project to extend Moodle. I 've already finished a mod (see this forum index) and some kind of calendar support is next. The main thing is, I have to have calendar support running AT MOST by Feb 5, no matter what.

So you see I was going to have to do this all by myself, which is pretty silly if I 'm the only one to use it and Moodle adopts something entirely different in the next release. I 've read the relevant discussions here (have to admit that I fiddled a bit with the "calendar as course mod" idea, but rejected it as it was rejected here, too), so let me describe my proposal and see if we could find some common ground:

1) Table Structure

CREATE TABLE `mdl_calendar` (
`id` int(10) NOT NULL auto_increment,
`ownerid` int(10) NOT NULL default '0',
`ownertype` enum ('user', 'course', 'group') NOT NULL,
PRIMARY KEY (`id`)
);

This table holds the separate "calendar entities" for Moodle. A single calendar entity holds many events for a SINGLE "owner", for example a specific course. The nice feature is that you can have many types of owners (users, courses, groups in this example) and each one has his own calendar. Then, (as you will see below) you can have the user view events from different "calendar entities", all of which are of interest to him. For example, you can show the events from his personal calendar and a course's calendar overlayed. When the user visits a different course, you can show his personal events and that other course's events. Or you can show everything at all times. This can be configurable from the user preferences, maybe.

CREATE TABLE `mdl_calendar_event` (
`id` int(10) NOT NULL auto_increment,
`calendarid` int(10) NOT NULL default '0',
`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 '',
`description` text,
`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`),
INDEX (`calendarid`)
);

The fields in mdl_calendar_event are named exactly as in your proposal, so there is nothing more to explain. This table associates events with their "owning calendar" using `calendarid`, for example events for a given course all have the same calendarid.

When we need to find the events to be displayed to the user, first of all we get an array of calendar ids. For example let's say the user's personal calendar is calendarid = 22 and the course he is viewing also has a calendar with calendarid = 32.

Next you make a query like "SELECT * FROM mdl_calendar_events WHERE calendarid IN ".implode(',', $calendarids).")" and there you go, all of the events for this user at your fingertips.

2) There should be a library calendarlib.php with the following functions:

calendar_add_event($calendar, $event)
calendar_update_event($calendar, $event)
calendar_delete_event($eventid)

The first two get one additional parameter, which is of course essential. Otherwise, same as your proposal. Also:

get_calendar_course($course = $GLOBALS['COURSE']->id)
get_calendar_user($user = $GLOBALS['USER']->id)

These two return the calendarid for the course and the user, respectively. So you can pass them to the calendar_add_event() and calendar_edit_event() functions.

calendar_create($ownertype, $ownerid)
calendar_delete($calendarid)

These two for creating and deleting calendars. For example, calendar_create() calls would be placed in the Moodle code when a new course or a new user is created. This is, of course, extremely simple.

3) & 4) I completely agree with your two last points

I hope you agree that there is no significant complexity increase associated with my proposal, while the filtering capabilities could be very useful (show events using different colors according to course or whatever, for starters).

I respectfully repeat that I am obligated to do something like this in the next weeks, so waiting is not an option. I would very much like to work on something that will benefit others (for example if we agree on the specs), but I 'll have to go on and do it no matter what. That's why I 'd like to "be part of" these developments if possible.

P.S.: Has anyone done some kind of "calendar viewing" code? That would be THE priority, considering how simple the interface is (just a few functions...)

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Gustav W Delius - šeštadienis, 2004 sausio 17, 00:08

I see that you are someone who will put a lot of useful work into this calendar and I am very happy to see that.

Your proposal contains the idea that an event should have an owner which can be either a course, a group or a user. Something similar has been suggested before and I am no longer against it.

I think your proposal could be simplified. I see no reason for the extra table mdl_calendar. Why not store the information about the user straight in the event table? I would simply add two extra fields to the events table. Instead of 'ownerid' and 'ownertype' I would choose 'userid' and 'groupid'. There is already a field 'course'. If 'userid' is not set then the event belongs to 'groupid'. If 'groupid' is also not set then it belongs to 'course'.

There is also no reason for a second argument to the functions add_event and update_event, the content for the extra fields could simply be passed as part of the $event object.

I already have some "calendar viewing" code because I simply adapted Webcalendar. I was going to post this as soon as Martin has added the event calendar to CVS. But given your interest I will post it this weekend. Webcalendar does all the layering that you are suggesting. That leaves plenty of time for improvements until February 5.

Webcalendar is not actually a particularly nice piece of software when compared to Moodle. So I don't want to discourage you from writing your own calendar viewing code. However given that you only have until February 5 using the existing Webcalendar code may be tempting.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - šeštadienis, 2004 sausio 17, 18:00

OK, thanks a lot Gustav (and Jon for joining the party)! approve

I've finally had a good look at all this and checked in code to CVS to allow the creation of the an "event" table. It's based on the code you sent above, Gustav, with a few modifications to a couple of fields (eg 'modulename' and 'timeduration'), plus I added fields for userid and groupid based on this discussion.

I also changed your scheme from updating all external plugin calendars to something more like authentication, where only a chosen plugin is used. This is because I would like to distribute all the plugins in Moodle without them needing to be active. Also, it would be best to hide calendar stuff from novices until it develops a little more.

So there is now a $CFG->calendar variable which is checked before executing any plugin calendar code. For now this can be simply set in the config.php

$CFG->calendar = 'webcalendar';

and when all this settles down we'll have a config in the admin pages, as well as adding multiple calendar support eg 'webcalendar;xcalendar;mycalendar'.

There is a "calendar" directory for the plugins, and a "webcalendar" for yours.

Gustav, you also now have editing rights to everything so I don't hold you up any more, but please tread carefully and check with me about major changes, as we are counting down towards 1.2 beta and unprecedented levels of golden stability.

Looking forward to seeing where calendars go from here!

Įvertinimų vidurkis: -

Re: calendar integration, webcalendar

Gustav W Delius - sekmadienis, 2004 sausio 18, 17:19

Martin, thanks for implementing the event table and the calendar plugin architecture.

I don't think I would like to put the webcalendar plugin into the main Moodle distribution. It is simply too big and too ugly for that. I expect that there will be much better code coming from the likes of Jon, A. Chavan, and Grant in the near future. Instead I would like to put the webcalendar into a calendar/webcalendar subdirectory of contrib. Hopefully I will have time to do that this afternoon.

And thanks for the CVS editing rights approve .

Įvertinimų vidurkis: -

Re: calendar integration, webcalendar

Martin Dougiamas - sekmadienis, 2004 sausio 18, 17:45

No worries.

I urge you to reconsider a smaller version of your plugin, if possible, that only includes the "glue" code from Moodle to webcalendar, and instructions to people about where to install webcalendar and how to modify it if necessary.

From what I think you said once before I understand that you had to modify webcalendar quite a lot. Is that still the case? Could it be possible to "plug-in" to a non-modified version of webcalendar? Or minimally-modified at least?

Įvertinimų vidurkis: -

Re: calendar integration, webcalendar

Gustav W Delius - sekmadienis, 2004 sausio 18, 19:30

The changes that have to be made in the Webcalendar code are not to drastic. Nevertheless it seems to me to be more convenient for Moodle users if they can download the modified version rather than having to perform the modifications themselves.

I think that it would be nice if the webcalendar plugin could be made available from the Moodle add-ons page http://moodle.org/download/modules/ as a single download.

Is there any reason why I should not to put a modified version of Webcalendar into cvs:/contrib/calendar/webcalendar ?

On a related topic: the event module is now obsolete and can be removed from http://moodle.org/download/modules/ (and from CVS).

Įvertinimų vidurkis: -

Re: calendar integration, webcalendar

Martin Dougiamas - sekmadienis, 2004 sausio 18, 21:01

The main reason I'm thinking is for those who maintain via CVS (in my case many many installations

) and don't want to download modules separately.

The other reason is for people who can't install modules (eg people using Fantastico). In the case of Fantastico, webcalendar is already seperately installable via a single click.

In an ideal world the webcalender plugin of Moodle could be web-configured to integrate any external webcalendar installation - but I totally understand if this is a hassle to write right now. It's just a suggestion - webcalendar will definitely be useful either way.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - šeštadienis, 2004 sausio 17, 22:29

The idea with the separate mdl_calendar was that if sometime in the future we wanted calendars to be owned by something else other than course, group, user, we could alter the table (the enum field) and have the option of doing it. Of course, we can also just add a new field with the scheme you suggested, but:

This could lead to complex and non-intuitive ownership resolution algorithms (if userid == 0 && groupid == 0 then owner = user etc) if we have many possible owner types
Of course it means we have redundant columns in the table
Database normalization theory is against this kind of thing

However, since:

Simplicity is always good, and admittedly your solution is by far the simplest there is
There are no plans for other owner types in the near future
I won't press for a "technically correct" solution when short of time

then I 'm all in support of your proposal, even more since Martin implemented it already in CVS.

As for the calendar viewing code, I did review in the past your mod based on WebCalendar, and yes, I didn't like WebCalender a lot... I think something both simpler and prettier would be nice to have in Moodle, and the time spent to code it will surely be gained by the time NOT spent to understand WebCalendar.

So, according to schedule, on Monday Jan 19 I 'm starting work on calendar-related code, and specifically on a mini-view for the main course page (the code will most probably reside in the course module's source somewhere). After that, administration/configuration options for this view maybe.

Adding events "by yourself" (for your personal calendar, e.g.) will probably come last. But don't quote me on it.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

W Page - sekmadienis, 2004 sausio 18, 00:36

Hello All!

I would ask that you consider a "MiniView" which would allow an admin/teacher to determine in specific areas,

What type of "MiniView" to have - Calendar or "Mini-Display (as described by Gustav) at the beginning of this thread.
If he/she even wants to place a "MiniView" in that location.
Where he/she wants to place the "MiniView" on a page, that is left, center or right block on the Home Page or Course Page.

The specific "MiniView" "real estate" areas would be,

Home Page
Each Course Page
My Moodle (Student Page) - based on page layout
My Moodle (Teacher Page) - based on page layout
My Moodle (Admin Page) - based on page layout

Given, from what I could understand, the calendar is to be layered, each of the above "MyMoodle's" would have Calendar Information specific and pertinent to them reflected in the "MiniView". An Admin/Teacher should also be able to determine what information is to be displayed in the Home and Course Page.

Just a few examples of "MiniViews",

Insinuendo.Org
The clock/menu in the upper right block. If you click on the word calendarat the lower part of the block, a calendar appears. If you click on clock, the clock appears again.

Albini.Net
The Calendar is near the bottom of the right blocks. The Calendar and Events are combined. Significant events are displayed at the top of the Calendar.

Bootsware.com
The Calendar and Upcoming Events blocks are at the top of the left blocks.

I hope you do not feel a non-programmer like myself is being brazen to suggest the above but I thought it would be OK to just throw it out there as an idea to share.

I hope you find it useful.

WP1

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - pirmadienis, 2004 sausio 19, 16:27

I 'm not sure what would be a good way to integrate the Mini-display (or whatever) config/admin options with the rest of Moodle at this time. What I had in mind is:

I 'll just write the code to DO the displays and add events to the calendar, hardwire it in my Moodle installation and test it.
The code WILL be configurable programmatically (e.g. do you want to see the user's events? The group's? The course's?) but this config will also be hardwired (meaning, I 'll change it "by hand" while developing).
When there's something other coders (Martin, Gustav, ...) can USE, I release it, they look at it and we reach a consensus about how to include it in Moodle.

This way I can work without making assumptions that possibly Martin won't like, and when the time comes to make the decisions we can discuss it.

As for your proposals, I agree with everything except maybe the Miniview placement (I don't think its that useful to move it around, having it on the left will probably be good enough). I 'll do that kind of thing and then we 'll see how/where to configure it.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - pirmadienis, 2004 sausio 19, 17:07

A good trick is to use a $CFG->somevariable to enable/disable it. When we are testing it's easy to define this in config.php for the whole site, and later we can talk about GUIs.

Įvertinimų vidurkis: -

Re: calendar integration, structure of event table

Gustav W Delius - sekmadienis, 2004 sausio 18, 17:11

Jon, you have won me around. I now agree with you that storing info about an event's user should be done through a second table rather than by adding more and more fields to the event table itself. I therefore now have the following proposal:

a) a new table 'mdl_event_participant' with fields 'id', 'eventid', 'participanttype', 'participantid'. The field 'eventid' points to an event in the table 'mdl_event'. The field 'participanttype' can have entries 'course', 'group' or 'user'. The 'participantid' then points to an entry in the corresponding table.

b) the table 'mdl_event' looses its fields 'courseid', 'groupid', and 'userid'.

c) there should be additional functions 'event_add_participant', 'event_update_participant' and 'event_delete_participant' to do the obvious thing.

I think the above proposal meets your database desing criteria and is more in line with Moodle practice.

I would like to hear your opinions on this proposal. Thanks to Martin I now have the power evil to implement something like this in CVS once consensus is reached.

Įvertinimų vidurkis: -

Re: calendar integration, structure of event table

Martin Dougiamas - sekmadienis, 2004 sausio 18, 17:23

I did think about this before I implemented it the way I did.

Firstly, these fields are not exclusive. If a user creates an event for a group, then set userid AND groupid AND courseid. If an event is set for a whole course, set userid AND courseid. If the user just creates an event for themselves, just set userid. userid is the author of the event, while the presence of courseid and groupid determine the scope of the reader. This makes it easy to pull out the various lists.

Secondly, this table will be accessed a lot, so speed is important. Avoiding a JOIN in common SELECTs is a good thing.

Thirdly, the possibility of 'participant' types beyond users, groups and courses is remote. If one thing is added, then adding a field is no big deal. If many are added then it's likely everything will need restructuring anyway so that can be dealt with then.

Įvertinimų vidurkis: -

Re: calendar integration, structure of event table

Gustav W Delius - sekmadienis, 2004 sausio 18, 17:31

Martin, thanks for the quick response. That settles the issue for now.

Įvertinimų vidurkis: -

Re: calendar integration, structure of event table

John Papaioannou - pirmadienis, 2004 sausio 19, 16:18

I wasn't as quick to respond, but it doesn't matter... What Martin says is very logical, and for now I agree with this approach too. We need to DO one thing or the other in order to see if there's some unobvious problem. Otherwise, both approaches can be argued for.

The thing with always setting userid is a nice touch, you can have the event "setter" for free. I hadn't thought of that! wide eyes

We just have to be a little more careful with the queries when layering (the downside).

I DO believe that a restructuring will be needed in the future. But for now let's get it working first.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

A. Chavan - šeštadienis, 2004 sausio 17, 03:19

Coincidently, I am working on a project where we need a Calendar with Moodle and we need this in a slightly shorter time frame than Jon. We need it by the end of this month. I have a couple of developers on my team who can help with the development. It doesn't always help having more cooks in the kitchen, but if there are any particular components you would like some help with please let me know. We haven't done any work on the calendar yet but our team has some experience working with other parts of Moodle.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - šeštadienis, 2004 sausio 17, 22:36

Hi, and nice to have you with us!

Well, the specs for the calendar are already in place, backbone code is in CVS as Martin said, so we need to start fleshing it out. I 'll start doing code for a course mini-view as I mention above. If you plan on starting with something yourself, just keep us informed to prevent wasted work.

Always nice to have more people on the team! big grin

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Grant McWilliams - sekmadienis, 2004 sausio 18, 07:06

It's nice to see this being done. It's funny how everyone needs the same thing. I was working on a php calander for my course format for the last week or so. I was attempting to make it as non-intrusive to moodle code as possible as I haven't been using moodle for very long and don't really know that much about how the rest works.

Grant

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - pirmadienis, 2004 sausio 19, 23:14

Started development today, slow pace...

Hacked 2 lines into course/format/topics/format.php
Added 2 functions to course/lib.php (one of them is the main "show me" function)
Added new file: lang/en/calendar.php
Added some new classes at the end of themes/default/styles.php

The main function shows this month, with events belonging to a user OR a group OR or a course. Any of these can be an array, for multiple selections. Starting day of week is most easily configurable (just tweak a number from 0 to 6 and all other calculations are done automagically).

Screenshot attached.

What do you think?

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - pirmadienis, 2004 sausio 19, 23:48

I don't mean to slow you down so soon, Jon blush

, but why the tiny month display? (I'm really asking)

A lot of people seem to like them (and I agree they do LOOK very cool at first) but I still can't see the usefulness of them... you need to click on them to get any information ... plus they break up information into months so at the end of a given month you can't see what is coming up next week. And the current date is already in the corner of everyone's screen.

We had a discussion a long time ago about this ... wouldn't a list format be better for the small display?

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - antradienis, 2004 sausio 20, 15:38

I was thinking of doing both of them, in fact. And then allow per-user configuration of what (if anything) he wants to see. Since the monthly view IMO needs more work, I chose to do it first. But there will also be a list format, don't worry. And everyone gets to use what he wants to.

As for the "why", it's just the fact that people around here want to see one. So there has to be one. It doesn't matter if I personally think it's useful (I do like it, but you have a point there), I have to work with them.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

W Page - antradienis, 2004 sausio 20, 01:42

Hello!

My nonprogrammer 1 1/2 ¢.

I think the "Mini-View" calendar looks good. The hyperlink dates let a user know there is some event for that day.

I would suggest,

A. If possible an area at the top or bottom of the Calendar block be used for the following (in any kind of combination),
1. The ability to navigate to another month/date similar to the Calendar block at Albini.net
2. Today's Events
3. Upcoming Events (like maybe 1 or 2 weeks ahead) - [The span of time could also be user determined - Admin/Teacher/Student]

B. Another thought is to have the following as separate blocks with the user having the ability to turn them on or off (that is, visible or not visible) like on Bootsware.com
1. Calendar - as in your display.
2. Today's Events
3. Upcoming Events

C. All three, the Monthly Calendar, Today's Events, and Upcoming Events in one block with the user given the ability to determine if they want all, two, or one of the features to display.

Therefore, a Calendar block could be - comprehensive - or - separated into different displays. This way a user could customize how they wanted dates and events displayed in a manner they best can absorb the information.

Myself, I like the Calendar view as you have it but I also like to know what is happening that day and what is coming up in the near future.

"Neato" Calendar "MiniView" Jon.

WP1

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Grant McWilliams - antradienis, 2004 sausio 20, 04:15

Here is what I came up with. I use the mini-view to link to each day. I wanted to have each class day shaded (haven't got to it yet). I was also playing with a larger calendar that would show links to assignments, classnotes etc.. I had thought about making a course format that was completely calendar with a drop down menu at the top that would switch between calendar view and and a dated topicish view (I call this view irregular).

Here is the link to a screenshot of my calendar.

Calendar

Thanks for letting me play in the shallow end.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Bryan Williams - antradienis, 2004 sausio 20, 05:18

Yeah baby, calendar looks real good! I like what you're doing with the design of your Moodle pages also. Any tips?

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Grant McWilliams - ketvirtadienis, 2004 sausio 22, 08:11

Bryan,
One word rgrep! Just select text with mozilla, right click and select "View selection source" then rgrep your moodle directory for any files that have what your looking for in them. This is how I've found out where everything is without asking a billion questions here. Then use CSS and your theme/yourtheme/config.php and styles.php for everything. I've tried not to mess with the moodle code too much other than create a new theme and a new course format. When I get it done I will through it up here so people can play with it.

Grant

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - antradienis, 2004 sausio 20, 16:05

About your proposals:

The option for monthly view/upcoming event view will be there for sure. I 've started thinking about also doing a weekly view, but that's just a thought, nothing definite yet. As for the "today" view, is it really different than the upcoming events view? I don't see a need for it...

I think there's no reason why someone should not be able to see more than one of these views if he wants to. We can get that to be configurable. But I 'm not sure what the best way would be to display them: in the same block, or in different blocks. Second solution seems more appealing, but one could argue that it uses more space on screen, so opinions would really be welcome.

Some new thoughts:

There is something that hasn't been discussed yet here: A student can take part in many courses. In this case, should the calendar displayed a course page (independent of format, month view or event view or whatever) display events from OTHER courses? My opinion is that it shouldn't. At least not by default.

So if it shouldn't, where can the student (or teacher) see ALL of the upcoming events? MyMoodle would be a nice candidate for this.

What does everyone think? Martin?

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Martin Dougiamas - antradienis, 2004 sausio 20, 16:11

Definitely MyMoodle (on the front page) ... that whole thing will be seriously revised after 1.2.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Lucia Siochi - ketvirtadienis, 2005 sausio 27, 05:17

Jon,

I'm trying to find out if or when a weekly view in the calendar will be implemented. I've looked around some and didn't really see anything about that other than in your posting. Are there any plans to implement it?

My apologies if the answer to this has already been posted elsewhere; if so, could you direct me there?

Thanks,
Lucia

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

John Papaioannou - ketvirtadienis, 2005 sausio 27, 23:09

Hi Lucia,

No, there are no plans for weekly view just yet. Considering that monthly view already exists, could you please explain a bit what a weekly view would offer?

And it's best if we discuss that in a new topic, this one is an ancient monster that should be forgotten now. wink

Jon

Įvertinimų vidurkis: -

Calendar development progress and issues

John Papaioannou - antradienis, 2004 sausio 20, 22:48

More activity today. I won't post the details since that would take a LOT of space, but:

If you have an interest in this thing: PLEASE take the time and AT LEAST read my notes. Many things call for choices, and opinions are needed! Even if you have no programming experience, you can read the notes and answer to the questions I ask inside. If you do have programming experience, then on top of that maybe you will want to review the code. I 've tried quite a lot to write comments, and they 're there to make your life easier.

So, after (hopefully) convincing you to help by discussing things wink

, let's get to the goodies:

Screenshot of monthly view AND upcoming events as course sideblocks:
http://zeus.it.uom.gr/moodle_dev/cal_sshot_jan20.gif

Notes and instructions for installing this on your Moodle: http://zeus.it.uom.gr/moodle_dev/calendar_devnotes.txt

Zip file with all code written so far (you need this to install or review the code):
http://zeus.it.uom.gr/moodle_dev/cal_dev.zip

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Mike Churchward - trečiadienis, 2004 sausio 21, 00:04

Firstly, I like the look; especially if you adhere to style standards so we can colourize to to our own looks.

I like the 'expired' idea. Can that number of days to show back be configurable?

For the today view, why not stick with the border? It works.

Upcoming events, you could seperate them with a line; either an horizontal rule or a bottom-border.

I think you want to display the description, but you could add another "Summary" field.

For event duration, I would just colour all affected days on the monthly view. In the Upcoming Events, display the duration as a range. i.e. "January 21 - January 23".

mike

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

John Papaioannou - trečiadienis, 2004 sausio 21, 17:31

First of all, thanks for the input!

Style standards: of course I adhere to them. Everything is customizable from the CSS, no need to touch the code.

I 've expanded a little on the "expired" idea, and made the code display all event dates/durations correctly (I hope!) without regard to when they happened/will happen. This means that viewing X days back is just a matter of adjusting the time window. However, this would conflict with the "display Y events maximum" option, since expired events would come first and take slots that should be used by upcoming events. So, it's very easy to make it configurable, but I don't know if it's a good idea.

The border is here to stay, I think...

I 've separated upcoming events with a line as you suggested, it looks much nicer now. The line is a HR, appearance configured from CSS.

The display has changed; now I display the "name" instead of the "description" field. This is probably "more correct", and of course shorter.

For event duration, Martin made a good point about splattering the monthly view with colors. It will end up just being unusable, so I 'm not sure about coloring all days in between. In the upcoming events block, as I said before I 've rewritten the date represenation code, so it displays nice things like "January 22 09:30 AM - January 23 10:30 AM" and "January 25 (09:00 AM - 11:00 AM)".

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Bryan Williams - trečiadienis, 2004 sausio 21, 00:33

My preference would be to only show the current date (or date selected on calendar) in yellow highlight, without a border. Sitewide dates of importance could be in white as shown, with significant course dates highlighted in the css gradient that's part of the theme package. A small legend at the bottom that explains color coding would make it intuitive. I also don't like weekend dates shown in red; why distinguish this in the users mind? thoughtful

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

W Page - trečiadienis, 2004 sausio 21, 01:20

I think it is OK to distinguish weekend dates. It just reminds the mind's eye that there is something different about those 2 days out of the week and aides in scheduling things and remembering things like study groups, weekend class, to study for a Monday exam etc.

WP1

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

John Papaioannou - trečiadienis, 2004 sausio 21, 17:38

Highlighting the current day is the first thing I tried. Unfortunately, what if the current date also has events? Then you either lose the "current" highlight (which confuses) or you lose the "event" highlight (which is not what we want). So the border is here to stay, but see my note at the end of the post.

As I 've written in yesterday's notes, the theme packages do not include may colors, so your options are limited. There is no color that consistently contrasts with the box background, so I have to add them in the CSS. If later all of this is included in Moodle, they can migrate to the theme package.

The legend is a good idea; I 'll work on it.

Weekend dates in red: also see this note.

NOTE: everything (colors etc) in the calendar is configured from the css. So if you don't like the red color, just edit the styles.php, delete one line:

.calendarweekend {
    color: red;
}

and you 're set. Same goes for the current day's border.

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

W Page - trečiadienis, 2004 sausio 21, 01:33

You are working so hard on this much needed addition to MOODLE. I have downloaded the file and will install it a bit later today. I will post something about then.

The Calendar and Upcoming Events blocks looks really good.

WP1

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Przemyslaw Stencel - trečiadienis, 2004 sausio 21, 06:18

Hi Jon,

First of all, thanks for working on it - it will be a very welcome enhancement of Moodle.
Here are my suggestions (quotes from your devnotes in italics):

user's events are shown with a gold background, sitewide event - white You will obviously need two more shade colours (course events and group events). How are you going to deal with days on which there are two or more types of events (what background then)?
The Moodle Themes don't have a variable that will consistently contrast with the background I think it would be best to create calendar-specific definitions in Moodle theme css files. Users will then be able to set their own colours for different types of events, as well as choose a border colour that will contrast well with their background.
There is no generic class in styles.php that makes whatever it's applied to smaller As above - just create new css classes.
Right now I use description. Maybe that can become too long? It might. Either use name field, or crop descriptions which are too long.

What do you think?

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

John Papaioannou - trečiadienis, 2004 sausio 21, 18:08

About multiple event types on the same day: I don't think there is a good solution for this. What I'm doing now is just giving "priority": first sitewide events, then course events, then group, then user. The first type of event that exists defines the background color.

CSS classes: I 'll add what the calendar needs to display itself, there's no other viable option.

Description vs Name: I 've changed that. Now it uses Name.

Thanks for the input!

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

A. Chavan - trečiadienis, 2004 sausio 21, 09:08

Hi Jon,

We read your notes and tried out your code. We were able to see the month view. But we were unable to add any events manually to the database. Which fields are required to get the event to show up in the month view and upcoming events block.

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

John Papaioannou - trečiadienis, 2004 sausio 21, 18:12

Just Name, Description and Timestart. If you want to try the colors, also set courseid, groupid, userid. Keep in mind that only events for the current user and the current course will show if one of these fields is != 0.

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Bill Burgos - trečiadienis, 2004 sausio 21, 11:21

Jon,

I thought that I would chime in with your project. Overall, I like the look of it. I'll add my comments after your topics and a few suggestions at the end.

--
* What's a good way to show which day is "today" in the monthly view?

I think that the present dark border would do fine. Any color variation would have to consider theme settings.
--
* Upcoming events: The display is WAY too crowded.

I think that it O.K. Instructors would have to keep their headings short. A lot of portal web pages keep their margins at about 120 pxl. Clicking on it could display more info. See below...
--

A few more things off the top of my head.

Clicking on the event. Could you use a popup? This would allow a quick, more detailed explanation with a link to the actual course or event if necessary.

Finally, I think that maybe a vertical stack of the months could show two months (i.e. Jan and Feb). This way people can see graphically events that might be two or three weeks away, but not visible because it is in the next month.

or

a week-based display running over the months, maybe allowing the viewer or scheduler to determine how many weeks can be displayed at one time (6 to 8 weeks maybe?). Instead of horizontally based arrows to shift from month to month, a vertical arrow that can shift the focus from week block to week block.

I hope this helps more than confuses,

Bill

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Bryan Williams - trečiadienis, 2004 sausio 21, 21:11

Jon,

I like some of Bill's ideas, especially the appearance of the calendar. Below is a screen shot of the calendar in my Personal Insight Journal program (FileMaker database). The arrows allow a user to scroll a day, month or year ahead in calendars. Button in middle brings you back to today. Selected date is highlighted in yellow with a white calendar background to show contrast as Bill suggests. Significant dates can then be in any lighter color, if the css theme cannot be used otherwise.

I really like Bill's idea regarding a pop-up window whenever you select a date on the calendar, much like how Glossary terms produce their definition in a pop-up when clicked. Seems like a no-brainer. This would probably eliminate the need for the Upcoming Events legend below the calendar.

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

W Page - ketvirtadienis, 2004 sausio 22, 00:59

Hi Jon!

You are working very hard on this "MiniView" and you are trying to include many of the thread poster's recommendtions.

I think the following about the "MiniView" Calendar.

The active date should be noted by a different background color than the rest of the calendar.
The weekend dates should be differentiated by text color.
Holidays should be differentiated by background color from the rest of the calendar.
A day with an event should be be identified by the presence of a hyperlink (with underline) or bold numbers.
If you want to be a bit fancy (and actually for expediency) it would be nice to allow a user to see a tiny/small popup window of the day's events by placing the mouse over the date. This would alleviate going to the main calendar page and waiting for the page to load.
- There should be a layout for the popup window based on what is scheduled, for example,
  - Exams
  - Projects
  - Labs
  - Group Projects
  - Miscellaneous
Make the link text a different color when an exam/quiz is scheduled.
Make the text a different color when a project/paper/essay etc is due.
Do not try to make a different text color and /or box background for every single type of event.
Whoever makes up a theme should include the color layout of the link text and backgrounds for the calendar so it blends in with the rest of the theme.
Maintain the ability to go back and forward a month.

I also think the following about the upcoming events/special dates feature,

Option to include or not include by admin/teacher and/or Student. I cannot really figure out which one should have this ability.
If a user ops in to use this feature it should be visible above the Calendar. Probably separated by a "Hardrule <HR>" or image from the Calendar.
Titles with a brief explanation which is hyperlinked to the more extensive explanation or a pop up window which displays more information.

I would really like to see this working with a layered type of "Calendar Module" Gustav was working on.

And so these are the suggestions of a non-programmer. big grin

Great work Jon!!

WP1

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Martin Dougiamas - ketvirtadienis, 2004 sausio 22, 01:07

Jon, can you start a new topic for this "minview"? This discussion is getting long!

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

W Page - ketvirtadienis, 2004 sausio 22, 01:14

I was thinking the same thing but didn't know if I should bring it up. shy

Since Martin, the MOODLE King brought it up, I felt I should make my thoughts known. big grin

WP1

Įvertinimų vidurkis: -

Re: Calendar development progress and issues

Grant McWilliams - ketvirtadienis, 2004 sausio 22, 08:18

All we need is a "class=" for every type of entry with blank styles and the rest we can customize to our liking.

class for:

weekends
weekdays
current day
events
important events (due dates?)
calender borders
forward and back buttons
date

etc.... As long as there are provisions in the code the rest can be easily customized.

Grant

P.S. I like the idea of having a popup when you click on a day. With my calendar it shows that day in a "dated topic view" when you click on it. I was going to (and still will) have to change moodle/course/edit.php to accept setting dates for each class day instead of a startdate and number of weeks. I just haven't had the time.

Įvertinimų vidurkis: -

Re: New attempt at calendar integration

Anu Valli - antradienis, 2004 vasario 3, 17:55

Hi!

Looks really good! Would it also be possible to link course material to calendar and is it possible to make summary of all calendar inserts?

Anu from Finland

Įvertinimų vidurkis: -