[Zug-sig] Aggregating User Group Calendars
cbc at unc.edu
Fri Feb 15 13:04:16 EST 2008
On 2/14/2008 11:49 AM, Alex Clark wrote:
> Hmmmm, anything on this yet? Assuming you want a "full page" calendar
> (similar to CalendarX, which has seen some Plone3 development recently,
> although I don't know the current state) I wonder if it would be
> totally out of the question to parse up some feeds and then create
> actual events on the site (then it would be easy to display them in
> the calendar).Just for reference, CalendarX was just re-released for Plone 3 last month. It is a product which provides a nice calendar view for just plain Plone events. I like 10x mo' bettah than the Plone4Artists calendar.
I hit reply earlier and it went to Tres. I'll reframe:
I just went through an eval of all the Plone 3 calendar products for my
CalendarX is far and away the best and it was just re-released for Plone
3 last month.
The problem is, I don't know of a Plone 3 (or any Plone) calendar
product which aggregates event feeds into a master calendar. They all
provide a calendar view for event objects on the site itself.
You might be able to re-tool a good starting point like CalendarX into
a feed aggregator. CalendarX is more of an updating of a Zope 2 product
for Plone into something that works well enough for Plone 3. While
Plone4ArtistsCalendar is proceeding on more of a Zope 3 component path,
it is still in an unreleased state for Plone 3. Plus, CalendarX just
looks and acts so much better and the Plone 3 version is so damn
configurable through Plone itself instead of the ZMI. The use cases for
it seem very well thought out.
Particularly ugly are the Plone products which take event
feeds and dump them into ordinary Plone event objects on the aggregated
end (and there are a few such products). That might get what we need.
Bake event feeds into event objects on zope.org and then the calendar
products "just work." Low hanging fruit.
I don't know how changes to the original event items being fed get
translated into changes on the aggregated objects using that approach,
however. It depends on things like short names not changing or
overlapping, and that just isn't going to happen. And it's all kind of
contrary to how feed aggregation is supposed to work.
A cleaner way might be this:
But that requires some work to make a mutant product out of both
feedmixer (or some feed aggregator) and CalendarX (or some calendar
product). The beautiful thing about CalendarX and other Plone calendar
products is they simply provide views for plain Plone event items,
rather than having content types of their own. Sticking feeds into them
is a fundamental change in how they work.
And then finally, the worst part of all. Plone event feeds out of the
box are sorted by *modification date* instead of start date. How brain
dead is that? It means everyone giving us a feed, assuming their feeds
are coming from Plone sites, will need to be hacked on the sending end.
The Plone event portlet gets it right. But the generic Plone RSS skin
goes by modification date as though one feed skin can rule all content
types. When event feeds are limited to five or ten items, you might not
even see the most recently starting events if even past events have been
more recently modified. As I can attest happens a lot.
And then there are the variety of event feeds. Not all ZUGs have a Plone
I suggested to Tres the lowest hanging fruit might be getting user
groups to be religious about duplicating their event posts on zope.org.
Although I know from experience that kind of effort both doesn't last
long nor would it be widely adopted.
office: 332 Chapman Hall phone: (919) 599-3530
mail: Campus Box #3300, UNC-CH, Chapel Hill, NC 27599
More information about the ZUG-SIG