EventAggregator

Annotated pages/HelpOnEventAggregator

440:5d1933e289c6
2014-04-09 Paul Boddie Improved event display, handling events that occupy instants in time, but avoiding unnecessary empty regions between events ending and subsequent ones starting at the same time.
paul@20 1
##master-page:HelpTemplate
paul@20 2
##master-date:Unknown-Date
paul@20 3
#format wiki
paul@20 4
#language en
paul@20 5
paul@20 6
== EventAggregator ==
paul@20 7
paul@222 8
The !EventAggregator macro for !MoinMoin can be used to display event calendars or listings which obtain their data through "aggregation" from pages belonging to specific categories (such as CategoryEvents) or from remote event sources.
paul@20 9
paul@222 10
<<TableOfContents(3)>>
paul@203 11
paul@20 12
== Creating Events ==
paul@20 13
paul@228 14
{{{#!wiki tip
paul@228 15
This documentation discusses only the creation of events on Wiki pages. It is also possible to collect or "aggregate" events from other sources, but the process of creating events using such sources is beyond the scope of this text.
paul@228 16
}}}
paul@222 17
paul@376 18
The easiest way to create an event is to hover over or select a day number in a calendar and to follow the "New event" link, or if the calendar is being shown as a list, map or table, to select the "New event" link below the calendar content. If you do not have a calendar set up, take a look at the instructions for [[#PreparingACalendar|preparing]] and [[#ShowingEventCalendars|showing]] calendars first.
paul@20 19
paul@330 20
Each event must be created on a new page belonging to the appropriate event category, if the calendar has been configured to only look for events in particular categories. The following action can be used to create a new event page (using [[HelpOnEventAggregatorNewEvent|EventAggregatorNewEvent]]) without looking at a calendar:
paul@47 21
paul@47 22
(!) <<Action(EventAggregatorNewEvent,Add an event)>>
paul@20 23
paul@47 24
Since each event is represented by a page, creating a new page based on an appropriate template is also sufficient. For pages belonging to CategoryEvents, you can do this by filling out and submitting this form (which uses EventTemplate):
paul@47 25
paul@47 26
<<NewPage(EventTemplate,Add an event page)>>
paul@20 27
paul@20 28
The event page describes the event in more detail, and the start and end dates of the event must be specified in a definition list so that they can be read from the page and displayed by the !EventAggregator. The EventTemplate provides some guidance, and all you need to do is to replace the `YYYY-MM-DD` placeholders with actual year, month and day values. For example:
paul@20 29
paul@20 30
{{{
paul@20 31
 Start:: 2009-06-28
paul@20 32
 End:: 2009-07-04
paul@20 33
}}}
paul@20 34
paul@21 35
You can add text which is more readable for humans provided that the `YYYY-MM-DD` format values are present somewhere in each entry. For example:
paul@21 36
paul@21 37
{{{
paul@21 38
 Start:: Sunday 28th June 2009 (2009-06-28)
paul@21 39
 End:: Saturday 4th July 2009 (2009-07-04)
paul@21 40
}}}
paul@21 41
paul@21 42
Obviously, duplicating the date information introduces a risk of this information becoming inconsistent, so beware!
paul@21 43
paul@104 44
=== Adding Time Information ===
paul@104 45
paul@104 46
In addition to date information, !EventAggregator understands time information; this is specified using the `HH:MM:SS` format (`HH` for hour digits in a 24-hour clock scheme, `MM` for minutes, and `SS` for seconds). The hour and minute details are mandatory; the seconds are optional. For example:
paul@104 47
paul@104 48
{{{
paul@104 49
 Start:: 2009-06-30 10:30
paul@104 50
 End:: 2009-06-30 11:00
paul@104 51
}}}
paul@104 52
paul@104 53
With no additional information, this indicates a time period from 10:30 (10:30am) until 11:00 (11am) without specifying a time zone. Consequently, such a period could be interpreted as applying ''in any location'' or ''in an agreed but unspecified location''. Where such things could lead to confusion, such as in the planning of an Internet meeting where people may join the meeting from many different places, time zone information can be specified. For example:
paul@104 54
paul@104 55
{{{
paul@104 56
 Start:: 2009-06-30 10:30 UTC+0100
paul@104 57
 End:: 2009-06-30 11:00 UTC+0100
paul@104 58
}}}
paul@104 59
paul@104 60
This indicates that the time is defined in a zone one hour ahead of UTC, thus defining a UTC period of 09:30 (9:30am) until 10:00 (10am). It is also possible to drop `UTC` and the last two minute digits where appropriate:
paul@104 61
paul@104 62
{{{
paul@104 63
 Start:: 2009-06-30 10:30 +01
paul@104 64
 End:: 2009-06-30 11:00 +01
paul@104 65
}}}
paul@104 66
paul@104 67
For an event occurring in British Summer Time (BST, GMT/UTC+01) this is a satisfactory means of describing the associated period. However, it can be more convenient to define an event in terms of the wall-clock time at a particular location. Sometimes, a regular meeting may occur at a particular time regardless of the introduction of daylight saving (or summer) time, and people can find it awkward to remember and choose the appropriate time zone, and thus the correct UTC offset. So instead, a time "regime" can be given. For example:
paul@104 68
paul@104 69
{{{
paul@104 70
 Start:: 2009-06-30 10:30 Europe/London
paul@104 71
 End:: 2009-06-30 11:00 Europe/London
paul@104 72
}}}
paul@104 73
paul@104 74
This indicates that in Britain (a "regime" defined for London, Europe) on the specified day, at 10:30am wall-clock time - that is, in the time zone reflected by properly adjusted local clocks - the event will begin, concluding at 11am according to the same clocks.
paul@104 75
paul@104 76
For most events, specifying a "regime" should be sufficiently accurate and unambiguous. However, some potential issues with specifying time information in such a way are [[#TimeProblems|described below]].
paul@104 77
paul@24 78
=== Supported Event Properties ===
paul@24 79
paul@24 80
As well as the start and end dates of an event, the following properties are also recognised as being part of an event description:
paul@24 81
paul@24 82
 Title:: the preferred name of the event in the calendar
paul@24 83
 Summary:: a synonym for title
paul@24 84
 Topics:: a list of topics related to the event - use a comma (`,`) to separate topic names
paul@51 85
 Categories:: a synonym for topics - note that this means "event categories", not "page categories" which are a distinct concept
paul@203 86
 Location:: the location of the event - this may [[#Showing_Events_on_Maps|position the event on maps]] if the location is known to !EventAggregator
paul@24 87
paul@24 88
These properties may be incorporated into representations or summaries of events.
paul@24 89
paul@24 90
Textual properties can be quoted in a limited way using the verbatim or monospaced text Wiki syntax. For example:
paul@24 91
paul@24 92
{{{
paul@24 93
 Summary:: <<Verbatim(EuroPython)>> 2009
paul@24 94
 Topics:: Python, <<Verbatim(EuroPython)>>, Zope
paul@24 95
}}}
paul@24 96
paul@70 97
=== Listing Many Events on a Page ===
paul@70 98
paul@70 99
Sometimes, it can be useful to list many events or event occurrences on a single page. For example, unlike something like an annual conference where a different event page makes sense for each occurrence of the conference, something like a regular meeting of a group of people might merit its own event page, but it would be inconvenient to make a new page for every single meeting occasion.
paul@70 100
paul@70 101
It is therefore possible to list many event occurrences on the same page by adding a new set of properties for each occurrence. For example:
paul@70 102
paul@70 103
{{{
paul@70 104
 Start:: Monday 1st February 2010 (2010-02-01)
paul@70 105
 End:: Monday 1st February 2010 (2010-02-01)
paul@70 106
 Summary:: MoinMoin User Group Meeting
paul@70 107
paul@70 108
Previous meetings:
paul@70 109
paul@70 110
 Start:: Monday 4th January 2010 (2010-01-04)
paul@70 111
 End:: Monday 4th January 2010 (2010-01-04)
paul@70 112
 Summary:: MoinMoin User Group Meeting
paul@70 113
}}}
paul@70 114
paul@70 115
To start a distinct event, just define a property that has already been recorded for the previous event on the page, if any. Usually, the start and end dates will be the most suitable properties for this purpose.
paul@70 116
paul@108 117
Be careful ''not'' to start a distinct event with a property that was ''not'' recorded for the previous event: the result will be the property being added to the previous event, even if the property appears adjacent to the rest of the new event definition.
paul@108 118
paul@335 119
=== Using Event Regions to List Events ===
paul@335 120
paul@335 121
To be certain of events being defined individually, it is possible to use event regions rather than rely on !EventAggregator to figure out where events begin and end in the page. For example:
paul@335 122
paul@335 123
{{{{
paul@335 124
{{{#!event
paul@335 125
 Start:: Monday 1st February 2010 (2010-02-01)
paul@335 126
 End:: Monday 1st February 2010 (2010-02-01)
paul@335 127
 Summary:: MoinMoin User Group Meeting
paul@335 128
}}}
paul@335 129
paul@335 130
Previous meetings:
paul@335 131
paul@335 132
{{{#!event
paul@335 133
 Start:: Monday 4th January 2010 (2010-01-04)
paul@335 134
 End:: Monday 4th January 2010 (2010-01-04)
paul@335 135
 Summary:: MoinMoin User Group Meeting
paul@335 136
}}}
paul@335 137
}}}}
paul@335 138
paul@335 139
By using event regions explicitly, it becomes possible for enhanced formatting and manipulation of the event data to be supported by !EventAggregator and other !MoinMoin extensions.
paul@335 140
paul@104 141
<<Anchor(TimeProblems)>>
paul@104 142
=== Occasional Problems with Times ===
paul@104 143
paul@104 144
In most circumstances, specifying a time "regime" should result in an appropriate time zone being deduced and thus defined for an event. In some circumstances, however, such wall-clock times can be ambiguous or ill-defined. For example:
paul@104 145
paul@104 146
{{{
paul@104 147
 Start:: 2010-03-28 02:30 Europe/London
paul@104 148
 End:: 2010-03-28 02:45 Europe/London
paul@104 149
}}}
paul@104 150
paul@104 151
In this example, the given times (2:30am and 2:45am) do not exist as wall-clock times: since British clocks observe GMT/UTC until 2am and then switch to BST (GMT/UTC+01), times between 2am and 3am do not really appear on clocks on that particular day. !EventAggregator will indicate a problem with events specified in such a way, but will still produce [[HelpOnEventAggregatorSummary|event summaries]] assuming that the intention was to schedule such a period as starting 30 minutes after 2am in GMT/UTC and ending 45 minutes after 2am in GMT/UTC, pretending that the time zone preceding the zone change has remained in force for the sake of the event.
paul@104 152
paul@104 153
Where the wall-clock time is effectively repeated, !EventAggregator will also indicate a problem with events defined using such ambiguous times. For example:
paul@104 154
paul@104 155
{{{
paul@104 156
 Start:: 2010-10-31 02:30 Europe/London
paul@104 157
 End:: 2010-10-31 02:45 Europe/London
paul@104 158
}}}
paul@104 159
paul@104 160
In this example, the given times (2:30am and 2:45am) ''do'' exist as wall-clock times, but such times appear ''twice'' on clocks: since British clocks observe BST (GMT/UTC+01) until 3am and then switch to GMT/UTC, times between 2am and 3am are visited twice by clocks on that particular day. For [[HelpOnEventAggregatorSummary|event summaries]], the assumption will be made that the intention was to schedule such a period as starting 30 minutes after 2am in BST and ending 45 minutes after 2am in BST, pretending (as above) that the time zone preceding the zone change is the correct zone.
paul@104 161
paul@104 162
Naturally, without explicitly specifying a time zone (as an offset from UTC), it is not possible to schedule the above event for the period from 2:30am until 2:45am in the GMT/UTC time zone. However, when !EventAggregator indicates a problem with the event specification, an organiser can be alerted to the problem and thus fully specify the event times. Where !EventAggregator provides an implicitly assumed time (and where the organiser ignores the warnings or does not want to specify the time zone), no-one will be late for (or miss) the event: the earliest possible time will have been chosen, giving participants the opportunity to return at the "correct" time should the assumed time have proven to be "incorrect".
paul@104 163
paul@62 164
<<Anchor(PreparingACalendar)>>
paul@62 165
== Preparing a Calendar ==
paul@62 166
paul@330 167
Before trying to show a calendar or trying to create any events, you must decide on where those events will come from. This can be one or more of the following:
paul@222 168
paul@330 169
 * A category in the Wiki containing pages for your events
paul@330 170
 * An event source which will provide events to the Wiki
paul@330 171
 * Pages that can be found using a particular search pattern
paul@330 172
paul@330 173
You can choose to show a calendar based on categories, event sources and a search pattern, obtaining events from each of these things and combining them into a single view.
paul@330 174
paul@330 175
If you decide to organise your events using categories, you can create a new category for the purpose of managing events by filling out and submitting this form:
paul@62 176
paul@62 177
<<NewPage(CategoryTemplate,Add a new category,,Category%s)>>
paul@62 178
paul@222 179
Available event sources should be defined on the [[EventSourcesDict|event sources]] page, and the source name is the piece of information to be noted when preparing a calendar.
paul@222 180
paul@222 181
Where categories are to be used, it is not strictly necessary to have a dedicated category for events, but having such categories can make event management easier by preventing event pages getting mixed up with other kinds of pages. And since pages can belong to more than one category, you can still assign event pages to other categories and yet isolate the event pages via their own category when you need to.
paul@222 182
paul@222 183
=== Defining Event Sources ===
paul@222 184
paul@222 185
!EventAggregator uses a page called EventSourcesDict to define providers of event information (unless the `event_aggregator_sources_page` configuration setting has been changed). Follow the instructions on the EventSourcesDict page to define new event sources.
paul@62 186
paul@62 187
<<Anchor(ShowingEventCalendars)>>
paul@20 188
== Showing Event Calendars ==
paul@20 189
paul@20 190
To show a calendar, use the !EventAggregator macro with a list of event categories. For example:
paul@20 191
paul@20 192
{{{
paul@20 193
## Show Events and Training categories.
paul@20 194
<<EventAggregator(CategoryEvents,CategoryTraining)>>
paul@20 195
}}}
paul@20 196
paul@20 197
The calendar, shown by default, is automatically filled out with the details of each event in the specified category (or categories), colouring each event period in an automatically generated colour.
paul@20 198
paul@222 199
To use event sources instead of categories, specify them using `source` parameters. For example:
paul@222 200
paul@222 201
{{{
paul@222 202
## Show events from the GriCal and FSFE sources.
paul@222 203
<<EventAggregator(source=GriCal,source=FSFE)>>
paul@222 204
}}}
paul@222 205
paul@330 206
To use a search pattern instead of categories or sources, specify it using the `search` parameter. For example:
paul@330 207
paul@330 208
{{{
paul@330 209
## Show events in pages below the MonthCalendarEvents page.
paul@390 210
<<EventAggregator(search=title:"MonthCalendarEvents/")>>
paul@330 211
}}}
paul@330 212
paul@330 213
This example lets !EventAggregator behave somewhat like the [[HelpOnMacros/MonthCalendar|MonthCalendar]] macro, although new events created using the "New event" link do not currently create appropriately named pages.
paul@330 214
paul@390 215
/!\ Be careful with the quoting of search terms: you should need to quote only the actual term and not the qualifiers. See [[HelpOnSearching]] for more general advice on search queries.
paul@390 216
paul@222 217
Categories can be combined with sources, thus aggregating "internal" and "external" events:
paul@222 218
paul@222 219
{{{
paul@222 220
## Show events from the Events category and the GriCal source.
paul@222 221
<<EventAggregator(CategoryEvents,source=GriCal)>>
paul@222 222
}}}
paul@222 223
paul@20 224
Specific periods can be defined using the `start` and `end` parameters. For example:
paul@20 225
paul@20 226
{{{
paul@20 227
## Show June and July 2009.
paul@20 228
<<EventAggregator(CategoryEvents,start=2009-06,end=2009-07)>>
paul@20 229
}}}
paul@20 230
paul@20 231
By using specific month values, a fixed window of time can be presented, displaying only events occurring within that period. It is possible to omit `start` or `end` in order to show all events up to (by omitting `start`) or starting from (by omitting `end`) a particular month.
paul@20 232
paul@20 233
There are special values which are significant. The `current` value refers to the current month and can be used with the minus and plus operators to refer, respectively, to months before and after the current month:
paul@20 234
paul@20 235
{{{
paul@20 236
## Show this and next month.
paul@20 237
<<EventAggregator(CategoryEvents,start=current,end=current+1)>>
paul@20 238
## Show this and last month.
paul@20 239
<<EventAggregator(CategoryEvents,start=current-1,end=current)>>
paul@20 240
}}}
paul@20 241
paul@20 242
In addition, the `yearstart` and `yearend` values refer to the first and last months of the current year:
paul@20 243
paul@20 244
{{{
paul@20 245
## Show this year's events.
paul@20 246
<<EventAggregator(CategoryEvents,start=yearstart,end=yearend)>>
paul@20 247
## Show events from last December to next January.
paul@20 248
<<EventAggregator(CategoryEvents,start=yearstart-1,end=yearend+1)>>
paul@20 249
}}}
paul@20 250
paul@35 251
=== Event Naming ===
paul@35 252
paul@35 253
The default calendar view shows event names once per week. However, you can choose to show an event name on each day an event occurs:
paul@35 254
paul@35 255
{{{
paul@35 256
## Show the name on every day.
paul@35 257
<<EventAggregator(CategoryEvents,names=daily)>>
paul@35 258
## Show the name once per week.
paul@35 259
<<EventAggregator(CategoryEvents,names=weekly)>>
paul@35 260
}}}
paul@35 261
paul@35 262
=== Navigation Controls ===
paul@35 263
paul@419 264
The above examples have all provided fixed views of known events. However, a set of controls can be added to a calendar in order to let users navigate different time periods. This is done by specifying a period of time:
paul@35 265
paul@35 266
{{{
paul@35 267
## Provide a navigable calendar.
paul@35 268
<<EventAggregator(CategoryEvents,start=current,end=current,calendar=monthly)>>
paul@35 269
}}}
paul@35 270
paul@419 271
Here, an optional `calendar` parameter, indicating the name of the calendar, is used to distinguish between this calendar and any others that might be displayed on the same page. Without it, any navigation might cause other such calendars to change their positions, too.
paul@419 272
paul@35 273
Without any time period, the calendar would show all events, and there would be no real need to provide navigation, since there would be no events outside the displayed period to navigate to. It is possible to omit either the `start` or the `end` parameter and still provide navigation, however.
paul@35 274
paul@419 275
=== Limits on Displayed Calendars ===
paul@419 276
paul@419 277
So that the display of a calendar does not result in a very large Web page being produced, a limit is enforced on the number of months or days that a calendar will show at any one time. This limit is defined in the `event_aggregator_max_duration` configuration setting or is given a default of 31 (months in the calendar view, days in the day view).
paul@419 278
paul@203 279
=== Showing Calendar Days ===
paul@203 280
paul@376 281
To view the individual days in a calendar, it is possible to hover over or select a day number and select the "View day" link. However, a calendar view can be set up using the macro as follows:
paul@203 282
paul@203 283
{{{
paul@203 284
## Show yesterday, today and tomorrow.
paul@203 285
<<EventAggregator(CategoryEvents,start=current-1,end=current+1,mode=day)>>
paul@203 286
}}}
paul@203 287
paul@203 288
In the above example, specifying a `mode` of `day` sets the resolution of the calendar to that of individual days, and thus the special value `current` refers to the current day (today) instead of the current month.
paul@203 289
paul@203 290
In the day view, time information is shown so that it becomes possible to see whether events conflict with each other. In addition, location information is shown above columns of events to help with event scheduling.
paul@203 291
paul@55 292
=== Assigning Templates and Parent Pages ===
paul@55 293
paul@376 294
New events can be added to a calendar by following the "New event" links provided when hovering over or selecting each of the day numbers; this opens the form provided by the !EventAggregatorNewEvent action. For all events belonging to a particular calendar, it can be convenient to assign a default template page, so that the information provided by such events is consistent. Thus, it is possible to specify such a template page using the `template` parameter. For example:
paul@55 295
paul@55 296
{{{
paul@55 297
## Specify a particular template page as the default event page template.
paul@55 298
<<EventAggregator(CategoryEvents,template=SpecialEventTemplate)>>
paul@55 299
}}}
paul@55 300
paul@55 301
It can also be convenient to add new event pages under a common parent page. This can be achieved by specifying such a page using the `parent` parameter. For example:
paul@55 302
paul@55 303
{{{
paul@55 304
## Specify a particular parent page as the default container for new events.
paul@55 305
<<EventAggregator(CategoryEvents,parent=Events)>>
paul@55 306
}}}
paul@55 307
paul@104 308
Creating an event called '''Meeting''' under a parent called '''Events''' will make the page '''Events/Meeting''', and this will be shown as '''Meeting''' in the calendar. However, if a different parent is chosen, such as '''Meetings''', then the full path to the page will be shown in the calendar: '''Meetings ?? Meeting'''.
paul@55 309
paul@51 310
== Showing Event Lists and Tables ==
paul@20 311
paul@20 312
A more plain view of events can be displayed by specifying the `mode` parameter as follows:
paul@20 313
paul@20 314
{{{
paul@20 315
<<EventAggregator(CategoryEvents,mode=list)>>
paul@20 316
}}}
paul@20 317
paul@51 318
The `list` value causes a list view to be employed.
paul@51 319
paul@51 320
Another alternative view can be chosen by specifying the `mode` parameter with a value of `table` as in the following example:
paul@51 321
paul@51 322
{{{
paul@51 323
<<EventAggregator(CategoryEvents,mode=table)>>
paul@51 324
}}}
paul@51 325
paul@51 326
This collects all appropriate events into a single table, applying colouring to the cells belonging to a particular event based on that event's topic (or category) information. By default, only the following topics (or categories) cause cell colouring:
paul@51 327
paul@51 328
 * `conference` - using the `event-table-category-conference` style
paul@51 329
 * `special` - using the `event-table-category-special` style
paul@51 330
 * `training` - using the `event-table-category-training` style
paul@51 331
paul@51 332
To define your own topic colours, edit the `event-aggregator.css` file which is provided with the !EventAggregator distribution, and then reinstall that file for each of the Wiki themes of interest. Topics involved in event colouring should be mutually exclusive: more than one such topic should not be specified for any given event.
paul@51 333
paul@203 334
== Showing Events on Maps ==
paul@203 335
paul@203 336
If a map is defined, as described below, and the name of such a map is given when using the macro, it becomes possible to allow a map view to be shown. For example:
paul@203 337
paul@203 338
{{{
paul@203 339
<<EventAggregator(CategoryEvents,mode=map,map=europe)>>
paul@203 340
}}}
paul@203 341
paul@203 342
The above example will show all events in the given category whose locations are known and are found to refer to places on the `europe` map.
paul@51 343
paul@203 344
=== Defining Maps ===
paul@203 345
paul@203 346
!EventAggregator uses a page called EventMapsDict to define and retain the available maps (unless the `event_aggregator_maps_page` configuration setting has been changed). Follow the instructions on the EventMapsDict page to define new maps.
paul@203 347
paul@203 348
=== Defining Locations ===
paul@203 349
paul@203 350
!EventAggregator uses a page called EventLocationsDict to define known locations (unless the `event_aggregator_locations_page` configuration setting has been changed). Follow the instructions on the EventLocationsDict page to define new locations.
paul@203 351
paul@203 352
== The Default View and Switching Views ==
paul@203 353
paul@203 354
The `calendar` value for the `mode` parameter causes the default calendar view to be employed, but you can switch the view - effectively changing the `mode` - using the links provided below the view produced by this macro. The map view is only available via a link if a map name has been given using the `map` parameter.
paul@24 355
paul@24 356
== See Also ==
paul@24 357
paul@47 358
 * HelpOnEventAggregatorNewEvent - an action providing a form for creating new events conveniently
paul@24 359
 * HelpOnEventAggregatorSummary - an action producing iCalendar event summaries