EventAggregator

Description

The EventAggregator macro for MoinMoin can be used to display event calendars or listings which obtain their data from pages belonging to specific categories (such as CategoryEvents) or from remote event sources. The start and end dates are read from the page describing each event, and the calendar is automatically filled out with the details of each event, colouring each event period in a specially generated colour. Maps showing event locations are also supported, given the availability of appropriate map images and location information.

Download & Release Notes

Installation

See the bundled documentation for installation instructions. EventAggregator is most conveniently installed using moinsetup.

Usage

Put <<EventAggregator(CategoryEvents)>>, substituting your preferred category names as the arguments to select categories from which events will be aggregated and shown. Alternatively, put <<EventAggregator(source=GriCal)>>, substituting your preferred event source (or sources, one per parameter) from which events will be aggregated and shown.

See also ActionMarket/EventAggregator for documentation on the EventAggregatorSummary action which provides iCalendar and RSS 2.0 download support for this macro, together with details of the EventAggregatorNewEvent action which provides convenient event creation through a form displayed on the currently shown page.

Examples

## Show multiple categories:
<<EventAggregator(CategoryEvents,CategoryTraining)>>

## Show a category's events as a list:
<<EventAggregator(CategoryEvents,mode=list)>>

## Show a category's events repeating the name in every consecutive day of an event:
<<EventAggregator(CategoryEvents,names=daily)>>

## Show a category's events for this and next month:
<<EventAggregator(CategoryEvents,start=current,end=current+1)>>

## Show a category's events for this and next month with navigation controls:
<<EventAggregator(CategoryEvents,start=current,end=current+1,calendar=events)>>

## Show the events published in a Wiki category and by the GriCal service for this month
## with controls and a map view showing a European map:
<<EventAggregator(CategoryEvents, source=GriCal, start=current, end=current, calendar=sources, map=europe)>>

Screenshots

Map View

(New in 0.7)

Day View

(New in 0.7)

Month Calendar View

Copyright

Copyright (C) 2008, 2009, 2010, 2011, 2012, 2013 Paul Boddie <paul AT boddie DOT org DOT uk>

Some patches provided by the following contributors:

Copyright (C) 2009 Cristian Rigamonti <rigamonti AT fsfeurope DOT org>

Some pieces of MoinMoin code were used in this work - typically pieces which demonstrate how to perform certain common tasks (as found in various macros and actions) - and are thus covered by the following copyrights:

Copyright (C) 2000-2004 Juergen Hermann <jh AT web DOT de>

Copyright (C) 2003-2008 ThomasWaldmann

Copyright (C) 2004-2006 AlexanderSchremmer

Copyright (C) 2007 ReimarBauer

License

GNU General Public License version 2 or later

Important Notices

In release 0.10, the EventAggregatorSupport module has been converted into a package. Upon upgrading, it may be necessary to locate the source and compiled module files (EventAggregatorSupport.py and EventAggregatorSupport.pyc) and remove them. Otherwise, these files may disrupt the functioning of the newly- installed software.

In release 0.9, much of the common support code has been moved to the MoinSupport distribution, thus introducing that distribution as a dependency which must be installed for EventAggregator to work. See the documentation regarding dependencies for further details.

Release 0.8.4 fixes time zone offset calculations for time regimes west of the prime meridian.

Release 0.8.3 fixes end dates in events aggregated from remote iCalendar sources.

Release 0.7.1 restores MoinMoin 1.9.x compatibility which was accidentally lost in the 0.7 release.

Release 0.6.4 fixes the download/subscription pop-up elements where calendars are open-ended, this having caused the macro to fail completely when showing such calendars.

Release 0.6.2 fixes various bugs in HTML production done by the actions. It is strongly recommended to upgrade from earlier versions to this release.

In release 0.6.2, support for MoinMoin 1.5.x has been dropped. Since usage of the Xapian search software is practically a necessary part of deploying this solution, and yet Xapian only became integrated with MoinMoin from version 1.6 onwards, few deployments should have involved MoinMoin 1.5.x.

In release 0.6, support for event times has been introduced. Due to the complicated nature of times, time zones, time regimes, and so on, the behaviour of the software may change in future versions to support common use-cases in a more convenient fashion. Please be aware that implicitly chosen or generated time or time zone information may change for events, particularly those whose times are ambiguous or ill-defined. It is highly recommended that the pytz library be installed - see the documentation regarding dependencies for more information.

In release 0.5, the "download this calendar" and "subscribe to this calendar" links have been fixed to return only events within the specified period and to work with day- and month-relative calendars. Users who have bookmarks in their Web browser or feed reader should replace these bookmarks by visiting the bookmarked page and acquiring new versions of these links, once EventAggregator has been upgraded.

Bugs

Fixed

• Fixed in 0.10.2: If the event detail is using the event parser, links are not clickable.

• Fixed in 0.8.3: Multi-day events from remote iCalendar sources specified at a day-level resolution are treated as being one day longer than actually specified.

• Fixed in 0.7.1: MoinMoin 1.9.x support is broken in 0.7.

• Fixed in 0.6.4: Calendars which are open-ended caused the macro to fail due to a bug in the preparation of the download/subscription pop-up elements.

• Fixed in 0.6.2: EventAggregator does not yet work with MoinMoin 1.9, although the repository version is very close to working fully.

• Fixed in 0.6.2: Calendars (as opposed to views of calendars) for download and subscription don't readily reflect what the download/subscription will contain, nor is there a convenient link to customise their content.

• Fixed in 0.7: Event metadata should support Wiki text so that links (for example) are shown correctly in the table view.

• Fixed in 0.5: Perhaps event colours should be based on the label instead of the page name, so that identically labelled events have identical colours.

• Fixed in 0.2: Event regions sometimes don't maintain the same height across multiple days, despite hacks to attempt to produce event boxes with a consistent height across consecutive days without using fixed dimensions.

Suggestions

• Added in 0.9: In the calendar view, the current day could be highlighted (with its own css class, like <div class="event-day-box event-day-current">)

• Views should expose more metadata such as topics and locations and possibly permit filtering according to such metadata.

• Support for recurring events would be nice. -- MelaEckenfels 2010-01-02 22:03:46

  • Multiple events per page is now supported - not quite recurring events, but movement in that direction. -- PaulBoddie 2010-02-16 23:38:02

• Support localised keywords when describing events.
• Styles should be obtained from a theme-independent stylesheet, if possible.

• Added in 0.7: Events at different times within the same day could be shown in order, possibly using a day view.

• Added in 0.9: The location of events should be offered as a pull-down menu. Event locations could also be used as the basis for the time zone of events.

• Added in 0.9: Allow the selection of events using more flexible search criteria such as <<EventAggregator(search=title:"Steel Panther", ...)>>.

• Added in 0.9: Support MonthCalendar-like page naming. Along with title searches, EventAggregator could present MonthCalendar data.

• Added in 0.9: Permit the specification of events in {{{ ... }}} regions that can be parsed and presented in different ways.

  • Potentially allow a heading in the block to be the title/summary.
  • The event parser should also support anchor generation regardless of any heading being specified.

• Allow the EventAggregatorNewEvent action to create and edit event regions and to be able to add events to regions grouping event regions.

• Added in 0.9: Add support for anchors to allow linking to individual events on multi-event pages.

  • Just making the link property support Wiki link expansion might be enough.
• Provide better support for markup in metadata.
• Add support for a category of event categories, at least as far as offering a selection of suitable categories for new events.

• Added in 0.10.2: Macro output is now cached, hopefully improving performance substantially.

Dependencies

The Xapian search software is highly recommended, if not technically essential, for the acceptable performance of the EventAggregator macro since the macro makes use of search routines in MoinMoin that can dominate the time spent processing requests. See HelpOnXapian for installing Xapian and getting acceptable performance.

The vContent package is required for the iCalendar functionality in EventAggregator. Archive links are available on the file browser page for the current snapshot.

The MoinSupport package is required for general functionality used by EventAggregator. Archive links are available on the file browser page for the current snapshot.

Discussion

• If you have a lot of events on a single page, I split them with headers (e.g. h2; see here: Single Event ). Now I would like that on the overview page (Overview Calendar) the link to the single wikisite also contains the anchor/fragment for a direct jump to the correct/clicked event (e.g. like this: Single Event with a fragment). In this examples I may have only a 2-3 events but on same pages I would add 10 or 20 events (I use this for a concert calendar; where a singlepages groups a full tour of a band together). I understand this maybe not so simple, because you have to define the anchor and what I see is that this anchor are only created if you use the TableOfContents Macro... -- MarcelHäfner 2012-09-26 12:25:32

  • I think I could probably add these anchors for events declared in their own regions (between {{{ and }}}) which I aim to introduce fairly soon in the 0.9 release, whereas anchors in general are only produced for headings. Since EventAggregator doesn't influence page rendering (it only parses pages), it can't generate anchors for the definition lists that define events. Special event regions would be rendered by an event parser and could influence the page and thus produce anchors. I suppose I could add another event property that allows the link of the event in the Wiki itself to be specified in a nice way: the link property could be used now, but there's no nice management of relative URLs or Wiki link expansion - more potentially interesting features! Maybe I should just get the 0.9 release out which should provide the event parser, but it might also be good if I also dealt with markup in metadata as well. I have to say that it's great to see EventAggregator in action, and you seem to have a very fancy Wiki indeed! -- PaulBoddie 2012-09-26 12:53:46

• First let me thank you for your great work. I'm now implementing this for my own site (some css changes, translating, etcetera), I also have some suggestions witch I may implement by mself, so I just want to give you some personal inputs, -- MarcelHäfner 2012-02-20 16:15:21

  • Thanks for the feedback! I've put some responses in below. -- PaulBoddie 2012-02-20 18:17:39

  • Location for the event should be a drop down... sure direct input is welcome, but a bit vary on the quality of the user input

    • This is on the secret "to do" list.

      • Great! Also I will try to add links to the location, so if a user click to a location he will receive a separate wiki pages with more information about the location (maps, images, text, etcetera)
  • Latitude and Longitude are too much for normal user (some even may have problem to find their own town on a map *evil*)

    • My solution has been to get positions from Wikipedia, but I'd like to have a nicer way of doing this.

  • Subpages with DATE variable. I would like to have a structure like "Events/YYYY-MM-DD/<EventName>" or just "Events/YYYY-MM-DD <EventName>". The benefit would be

    1. Easier to remove old events (e.g. rm Events/2012*)
    2. Searching for events possible with the normal title search (e.g. 2012 Steel Panther; will show every Event from the BAnd Steel Panther in 2012)

    3. Grouping them together for other usage (e.g. Events from March:

    Some people incorporate the date into page names manually, but it might be nicer automated for those that want it. As for the searching, the only reason EventAggregator uses categories is because I originally thought that this was fast without Xapian, but it actually isn't. I thought that general search criteria was also in the secret "to do" list, but my intention is actually to allow something like <<EventAggregator(search=title:"Steel Panther", ...)>> and have a Steel Panther calendar.

    • OK, I use for now a parrent page like "/event/2012", so main calender is on a wiki page called "event" and the subpage 2012 is now a archive page (mode=list) for my past events. Only little little drawback is I have to remember to change the the macro every year I made a small patch to add the startdate to the parent page name. Now I use the macro like parent=Events/$DATE.

      --- /home/moin/source/EventAggregator/EventAggregator-0.8.3/actions/EventAggregatorNewEvent.py  2012-02-15 00:24:18.000000000 +0100
      +++ EventAggregatorNewEvent.py  2012-02-25 17:32:46.000000000 +0100
      @@ -665,6 +665,9 @@
       
               # Use any parent page information.
       
      +        if "$DATE" in parent:
      +            parent = parent.replace("$DATE","%04d-%02d-%02d" % (start_year, start_month, start_day,))
      +
               full_title = getFullPageName(parent, title)
       
               # Load the new page and replace the event details in the body.

      • Compatibility with MonthCalendar would be useful, yes. -- PaulBoddie 2012-02-25 21:16:46

        • This will arrive in 0.9, although I'm using things like @DATE@ and @TITLE@ to specify an explicit page name separate from the title, which is retained and used to fill out the event metadata. -- PaulBoddie 2012-11-17 23:20:19

  • Limit Categories. I have a Wiki with a lot of Categories witch do not have any common with an event, so it would be nice to choose somewhere witch categorie are "available" for events.

    • Agreed. Maybe a meta-category is required. :-)

• Some other questions/suggestions,

  • I've replied inline again! -- PaulBoddie 2012-02-21 23:06:51

  • iCalendar Export for the whole calender or a view is nice, but if you have single events without an connection together you only want to export a single event. I'm thinking about an action or a macro that I can put on the event page itself.

    • I'm intending to allow the specification of events in {{{ ... }}} regions which will then be parsed by an event parser. This won't have much effect on the existing features, but it will make it possible to present events in a nicer way on the event page and maybe make them editable. There could then be links to iCalendar resources for each event. (I actually intend to develop support for serving up events separately in different formats.)

  • A switch to disable all those extended options (EventAggregatorNewEvent.py). Because normal user have no idea about utc, local time zone, etcetera... (for me I comment out this section or will hide it with css)

    • Maybe there needs to be an advanced mode for time information and/or the location could be taken from the other event details.

  • Why do you use Verbatim Macro for Summary, Locations, etcetera?

    • The only reason I can think of is that if you enter something like "EuroPython" and it gets added to the event page, it may appear as an inactive link and then you have to play with the syntax. And I think that I didn't have the capability to handle this elegantly - transform it to plain text for the labels in the different views - and so I special-cased the verbatim syntax. Moin's plain text formatter is pretty broken, especially in 1.9, so it isn't usable for this purpose...

  • For my I would like to have the topics more as links to other pages (maybe not good for everyone)... I will use this for band names, so I can link to bands with will play on an event. Because than I can link back from a band page to the events the playing / played. I guess I will dig a little bit in your source code around

    • For topics, I probably don't need to do such hacks. You can see that stuff in these fields gets formatted in the list and table views, so I should just let people put what they want in there. However, my first point about just wanting text to be plain text still applies.

  • Headings - I'm in love with headings so normaly every wiki pages needs a h1 heading  = text = . at the momentan my event template contains something like @ PAGE @, but better whould move the summary text into the heading and remove the summary... but that gives complication with the calender view, etcetera.. but I do not like duplicated content on the same pages... well

    • Initially, there was only one event per page, but you can now have several per page and it's easier to handle this information if it all appears together. I'm intending to use blocks (described above) to group information in the future and this might permit headings inside the blocks which are then easier to associate with each event.

  • Translation, I extracted the getext stuff and created a new po file, this one i just added to the default language file (e.g. for german http://hg.moinmo.in/moin/1.9/file/3b1b875eb4f2/MoinMoin/i18n/de.MoinMoin.po). Do you know any better solution?

    • If someone could give me a hint about how to load extensions to the built-in translations, that would be great. Otherwise, I think you can define a WikiDict called GermanDict and get the translations incorporated into the Wiki that way. I also intend to allow translated keywords in the event descriptions (see above).

Verbatim

The action "EventAggregatorNewEvent" use for certain fields the macro "Verbatim". This macro can't handle a comma in the text, 'coz it is used for separting arguments. if a user save something like this   Summary:: <<Verbatim(Red, 101 Adrenaline)>>  the macro fails with an error message. Also its possible that the user use quotes, and so on . I modified the macro, do you have any other idea?

--- /MoinMoin/macro/Verbatim.py 2013-08-13 10:17:47.000000000 +0000
+++ Verbatim.py 2013-10-12 12:44:01.359222708 +0000
@@ -8,5 +8,5 @@
 
 Dependencies = []
 
-def macro_Verbatim(macro, text=u''):
-    return macro.formatter.escapedText(text)
+def execute(macro, args):
+    return macro.formatter.escapedText(u''.join(args))

now even something like this  ",asdf",tes,"t  works

-- MarcelHäfner 2013-10-12 12:57:05

• I have previously wondered whether I should bother with the Verbatim macro as it is mostly used to prevent spurious links. However, I think I can quote the text like this:

  <<Verbatim("Hello, world")>>
  <<Verbatim("Hello, ""world""")>>

  The latter puts quotes around world. Maybe this is a solution. -- PaulBoddie 2013-10-12 14:53:51

  I've now fixed the issue in hg in the underlying MoinSupport library. At some point in the near future, there will be new releases of all these projects. -- PaulBoddie 2013-10-12 17:15:57

  • OK, thanks installed and is working. Drawback is that in the calender view the event name is now with quotes around. E.g. before  Shakra , now  "Shakra"  (Example)

  • I guess I need to refine my quoting. -- PaulBoddie 2013-10-14 23:19:03

  • I looked into this and it's actually the way I extract text from formatting without using a parser/formatter combination. This should be fixed in MoinSupport now. -- PaulBoddie 2013-10-15 16:19:17

Caching for better performance

I have a few hunderd events on my wiki (and I do not really want to delete the old outdated events; i like to have them for archive). The wiki itselfs runs unfortunately in a shared hosting environment and if I got a certain higher server load (loadavg) the e.g. calendar view gets a bit too slow (over 5-10s pageload, even with xapian enabled). I modified the following, any other ideas?

• In your source code the option "event_aggregator_max_cache_age". If i would set this to e.g. 4h  event_aggregator_max_cache_age = 18000 . But a short test showed not much different in calender mode.

• I modified (copied) the macro to create a "EventAggregatorCached.py" macro, with  Dependencies = [] . If I create a new event, I have to use the macro refresh to see it (so caching is working)

-- MarcelHäfner 2013-10-14 22:44:15

• I don't really understand the Dependencies setting (is there any documentation anywhere?), but if that fixes the problem then maybe it is the right thing to do. -- PaulBoddie 2013-10-14 23:19:03

• I've decided that it probably is the right thing to do, so it's in hg now. Thanks for the suggestion! -- PaulBoddie 2013-10-15 16:19:17

• Well, after further investigation, I've had to revert this: it broke non-script-based navigation because Moin's caching support doesn't pay attention to request parameters. I may make a patch to Moin to add such support and re-introduce this caching in future, though. Maybe improving the caching support would be generally good for Moin, anyway. -- PaulBoddie 2014-01-22 18:17:00

  • Because caching is very useful here, I've been developing some patches for Moin to support a pageparams caching mode. The branch supporting it in EventAggregator is caching-pageparams and the patches are as follows:

    • patch-cache-pageparams-1.9.diff

    • patch-cache-pageparams-1.8.diff

    Hope this is still of interest! -- PaulBoddie 2014-03-29 15:09:23