plone.app.event - new eventtype for plone

[thet]

Proposer: Johannes Raggam
Seconder: None as yet

Motivation

The current event type is in need of a major overhaul. The intention of this PLIP is to provide a new event engine by a major refactoring and reimplementation:

• [a] Encapsulation and independence: All event related code should reside in a seperate package (splitted into other packages, where appropriate). Plone should be least dependend on plone.app.event. Best would be that one can deinstall this feature completly.
• [b] Archetypes and Dexterity awareness: plone.app.event should provide the ATEvent content type (factored out from ATContentTypes) and also Dexterity behaviors, which can be used in Dexterity types.
• [c] Standards compliancy: the iCalendar / RFC5545 standard is wonderful flexible, so plone.app.event should provide support for it by allowing ical exports. This is also available for the current ATContentType based implementation, but plone.app.event aims to improve it. Sometime it might also support iCalendar import and Plone could also act as a caldav server.
• [d] Recurring events support based on the RFC5545 standard.
• [e] A modern dateinput widget.
• [f] Features like whole-day-events.
• [g] Timezone support.

Proposal & Implementation

Encapsulation and independence: plone.app.event provides the Archetypes based type and the Dexterity behaviors via two other subpackages in that package: at and dx. Based on installed features (Products.ATContentTypes or plone.dexterity, respectively), eather of those subpackages are included via the zcml:condition statement. The calendar and event portlets were moved from plone.app.portlets into plone.app.event, where they belong semantically - thus improving encapsulation and independence. The calendar portlet was completly refactored. The functionality of the CalendarTool (portal_calendar) was reimplenented. Important settings from the calendar-controlpanel are now available in the event configlet. Since the calendar portlet was the only consumer of the CalendarTool, the CalendarTool, the calendar controlpanel and the dependency to Products.CMFCalendar can be dropped. The new plone.formwidget.datetime implements archetypes and z3cform based widgets, so the old datetime widget can be dropped. Python-dateutil provides recurrence calculations based on the RFC5545 standard - plone.formwidget.recurrence provides a awidget for recurrence and Products.DateRecurringIndex an appropriate index as a drop-in replacement for Zope's DateIndex. The iCalendar package was improved and is now used for plone.app.event to provide icalendar serialization. The timezone support is based on the pytz package. Plone has to define a portal timezone now and every event can define another timezone, if wished. User timezones are planned. Whole day events get their starttime set to 0:00 and endtime set to 23:59:59 - thats should be feasable in most cases (excluding any scientific events...).

Deliverables

• plone.app.event: ATEvent, DX behavior, Configlets, iCal export, timezone support, util functions.
• plone.event: Recurrence calculations, util functions, base timezone support. Might be dropped, if we decide to provide everything in plone.app.event.
• Products.DateRecurringIndex: Drop in replacement for DateIndex with recurrence support. Every occurence of an event gets an index entry, so events for a specific date range can easily be searched.
• plone.formwidget.datetime: Datetime widgets for Archetypes and z3cform based on JQuery utils Dateinput.
• plone.formwidget.recurrence: Recurrence widget, which generates an RFC5545 compatible recurrence definition string.
• icalendar: iCalendar serialization/deserialization library.

Plone.app.event adapted branches of core packages:

• Products.CMFPlone
• Products.ATContentTypes
• plone.app.portlets
• Products.PloneTestCase (not needed, if Plone drop's its dependency on it)

Risks

• Third party packages which rely on ATCT internals may break (although ATCT should still provide BBB imports from plone.app.event).
• Third party packages which rely on portal_calendar may break.

Progress

See:  https://github.com/collective/plone.app.event/blob/master/TODO.rst

Code

Use:  https://github.com/collective/plone.app.event

For the other packages, look into:  https://github.com/collective/plone.app.event/blob/master/sources-ro.cfg

For the PLIP buildout, use:  https://github.com/plone/buildout.coredev/blob/4.2/plips/plip10886-event-improvements.cfg

Notes

This PLIP is an update of  http://dev.plone.org/plone/ticket/9302

Sprints, where plone.app.event was developed:

• Snowsprint 2007, Vorarlberg, Austria (Dateable, a predecessor of plone.app.event).
• Cathedral 2010 sprint, Cologne, Germany (start of the package plone.app.event based on vs.event and ATEvent).
• DZUG Tagung 2010, Dresden, Germany.
• Plone Conference 2010 Bristol, United Kingdom.
• Artsprint 2011 Vienna, Austria.
• Buschenschanksprint 2011, Berghausen, Austria.
• BarSprint 2011, Ljubljana, Slovenia.

[vincentfretin]

I suppose we should close #9302 as duplicate.

[vincentfretin]

Johannes, you forgot to add "An updated Calendar portlet that uses the recurrence index." in the deliverable.

Finally we don't use collective.calendarwidget at all. We use collective.js.jqueryui which ship with all jqueryui (except the tabs plugin which conflicts with plone.app.jquerytools), it includes the functions needed for the i18n of the datepicker and will contain soon a new theme more integrated with sunburst.

[vincentfretin]

(In [38685]) Copied PLIP cfg for event improvements (refs #10886)

[vincentfretin]

jquerui-min.js has a size of 192KB.

I think collective.js.jqueryui should be splitted into two packages:

• collective.calendarwidget which contains UI Core, the datepicker widget, the date i18n functions, the theme. Total of 47KB.

• all other plugins in collective.js.jqueryui: 144KB

And only collective.calendarwidget will be needed in a default Plone installation.

[hannosch]

Replying to vincentfretin:

jquerui-min.js has a size of 192KB.

I think collective.js.jqueryui should be splitted into two packages:

• collective.calendarwidget which contains UI Core, the datepicker widget, the date i18n functions, the theme. Total of 47KB.

• all other plugins in collective.js.jqueryui: 144KB

And only collective.calendarwidget will be needed in a default Plone installation.

47kb for a date picker is still a lot.

I think the framework team decided earlier that jqueryui is not an acceptable dependency as a whole. So it might be good to explain in more detail which date picker solutions have been considered and what their pros/cons are.

[ajung]

The datepicker JS code is only 3KB or so + some CSS (which is currently 21KB but obviously containing a lot of unrelated styles) + a language specific JS file with the translation (1KB)...so with some cleanup and language-specific loading of JS files it should be possible to bring the complete datepicker code to under 10KB or so.

Replying to hannosch:

Replying to vincentfretin:

jquerui-min.js has a size of 192KB.

I think collective.js.jqueryui should be splitted into two packages:

• collective.calendarwidget which contains UI Core, the datepicker widget, the date i18n functions, the theme. Total of 47KB.

• all other plugins in collective.js.jqueryui: 144KB

And only collective.calendarwidget will be needed in a default Plone installation.

47kb for a date picker is still a lot.

I think the framework team decided earlier that jqueryui is not an acceptable dependency as a whole. So it might be good to explain in more detail which date picker solutions have been considered and what their pros/cons are.

[ajung]

I think there are some open points and risks with the recurring support (however I don't have a detailed overview over recurrence issues (Johannes knows best)). I think it should be safe to ship Plone 4.1 with plone.app.event as ATEvent replacement (w/o recurrence support) and address recurrence support in Plone 4.2. So recurrence should not block the acceptance of this PLIP.

[thet]

Replying to ajung:

I think there are some open points and risks with the recurring support (however I don't have a detailed overview over recurrence issues (Johannes knows best)). I think it should be safe to ship Plone 4.1 with plone.app.event as ATEvent replacement (w/o recurrence support) and address recurrence support in Plone 4.2. So recurrence should not block the acceptance of this PLIP.

Well, i go with that. Recurrence should not block the acceptance of this PLIP. The more important step is to synchronize ATContentTypes and plone.app.event and get it fully working.

But recurrence support can be implemented in a somehow transparent way. Reindexing would be the major migration step, as far as i can see. But i guess, some other difficulties will arise.

[esteele]

Your PLIP has been accepted for consideration for Plone 4.1.

Framework Team voting on this PLIP was: Alec +0 Craig +1 Elizabeth +0 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross --

The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.

[ldr]

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

[tom_gross]

Replying to ldr:

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

Is it because of the size, or are there other reasons? There is a standalone implementation of the datepicker-widget, which could be used.

[tom_gross]

Replying to tom_gross:

Replying to ldr:

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

Is it because of the size, or are there other reasons? There is a standalone implementation of the datepicker-widget, which could be used.

 http://marcgrabanski.com/articles/jquery-ui-datepicker

[esteele]

Replying to tom_gross:

Replying to ldr:

Implementation note. FWT is against adding a jQuery-UI dependency to Plone at this time.

Is it because of the size, or are there other reasons? There is a standalone implementation of the datepicker-widget, which could be used.

Steve McMahon has a good summary on his blog, here:  http://www.stevemcmahon.com/steves-blog/tools

[thet]

PLIP ready for review. For an updated information what was done, please see:  https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.1/plips/plip10886-event-improvements.txt

[eleddy]

some how there are two tickets with this number. review here: (In 46012) initial review for event improvements, refs #10866

[cah190]

(In [46346]) Review for PLIP 10886. Refs #10886

[thet]

about the current status:

vincent fretin, rok garbas and me attended at the artsprint [1] in vienna in the first week of february this year and made some good progress:

• fixed many bugs, mentioned in the plip reviews
• optimized archetypes.datetimewidget behavior
• discussed some plans, how to further improve the package and code

structure

• partly migrated the test infrastructure to plone.(app.)testing
• solved the timezone troubles with Zope's DateTime (by using pytz and

introducing a timezone field for the event object and storing DateTimes in UTC only...)

• prepared some javascript testing stuff to be used for

js.jquery.recurrenceinput recurrence widget.

there are still some things to be done - see the current todo list [2].

[1]  http://www.coactivate.org/projects/artsprint2011 [2]  https://svn.plone.org/svn/plone/plone.app.event/trunk/TODO-artsprint.txt

[thet]

sorry for the square-brackets-links

[vincentfretin]

Please see #9353 and #11564 for timezone issues.

[esteele]

Moving to 4.2 milestone. I want this one. :)

[thet]

status update:

vincent fretin, rok garbas and johannes raggam attended at the artsprint [1] in vienna in the first week of february 2011 and made some good progress:

• fixed many bugs, mentioned in the plip reviews
• optimized archetypes.datetimewidget behavior
• discussed some plans, how to further improve the package and code

structure

• partly migrated the test infrastructure to plone.(app.)testing
• solved the timezone troubles with Zope's DateTime (by using pytz and

introducing a timezone field for the event object and storing DateTimes in UTC only...)

• prepared some javascript testing stuff to be used for

js.jquery.recurrenceinput recurrence widget.

there are still some things to be done - see the current todo list [2].

[1]  http://www.coactivate.org/projects/artsprint2011 [2]  https://svn.plone.org/svn/plone/plone.app.event/trunk/TODO-artsprint.txt

[eleddy]

Thanks for all the work on this! Let us know when it's ready for another review. This PLIP is long overdue :)

[vincentfretin]

Hi,

I sold the recurrence functionality to a customer, so I quickly needed something functional. I continued the plone.formwidget.reccurence widget, it serializes and deserializes the rfc string perfectly now, but it's not internationalized and there is no automated tests on it. The widget will be normally reimplemented by Rok for the next sprint ( http://www.coactivate.org/projects/buschenschanksprint-2011/project-home)

The plone calendar portlet is not functional with recurring events. Instead of using the portlet I use Solgema.fullcalendar which now supports recurring events from plone.event. This works really well.

There are issues with the timezone field on the event content type, it is handled after the start and end dates, so it always default to the portal timezone. So for now, I only enable one timezone for the portal to not have weird issues.

I will put a Plone 4.1b1 + plone.app.event site on production the next week with the current work status.

[thet]

thank you vincent! awesome work. i'm looking forward for the buschenschanksprint.

[eleddy]

hey guys - we are looking at a feature freeze on June 30th. Are you guys close to being ready for reviews yet?

[rossp]

FWT has approved a delay of one week for the implementation. So happy coding and have the implementation done next Monday!

[eleddy]

Any update here? We are considering pushing this to 4.3 if there are a lot of changes.

[thet]

hey, sorry for replying late... i'm going to summarize the status tomorrow in more detail.

but yes, please push it to 4.3. we've made a lot of progress, but not ready yet. we did a lot of refactoring, because we rethought some design decisions and want to ship a solid product.

we want to push out a usable release canditate *before* any plip implementation deadline of 4.3 - i promise. so people can use it in the wild and report bugs.

[eleddy]

Replying to thet:

hey, sorry for replying late... i'm going to summarize the status tomorrow in more detail.

but yes, please push it to 4.3. we've made a lot of progress, but not ready yet. we did a lot of refactoring, because we rethought some design decisions and want to ship a solid product.

we want to push out a usable release canditate *before* any plip implementation deadline of 4.3 - i promise. so people can use it in the wild and report bugs.

Glad to hear it! No worries. Look forward to the details and we'll just plan on reviewing it later.

[thet]

i wrote a blog article which gives more details about the ideas and the status of plone.app.event. see here:  http://bluedynamics.com/articles/johannes/whats-up-plone.app.event

[eleddy]

thanks for the update! looking forward to reviewing the changes for 4.3. whenever its ready, we are ready to do reviews!! just change the status.

[trs22]

One of my users has a case where they have a recurring event that happens at multiple locations. For example:

• Date A, Location X
• Date B, Location Y
• Date C, Location Z

After reading this PLIP and the accompanying documentation, it doesn't look like the RFC specifies any date/location correlation, so this may not be within the scope of the implementation.

However, I figured I'd present the idea to see if anyone else had a similar use case, or if it struck a chord with anyone!

Thanks!

--Tim

[rossp]

The FWT has wrapped up work on 4.2 and can start work on 4.3 whenever we have PLIPs to review. So can you as proposers or implementers please check in on your PLIPs and let us know what the status is and when we can expect issues to be addressed and implementations complete so we can review them for merge in 4.3.

[thet]

We had much progress in the last months here. Lennart worked on a recurrence widget and an alternative Recurring Date Index, Rok adapted the icalendar library, i dropped CalendarTool and CMFCalendar dependency, refactored calendar portlet and recently i began developing dexterity behaviors (out of original PLIP scope, but a need for a current project).

The biggest stuff left to do now is:

• Finishing plone.formwidget.datetime (tests, z3cform integration, localization).
• Tests (new ones, refactoring old ones).
• Removing/deprecating legacy code from CMFPlone, including tests (CalendarTool, datetime widget, calendar controlpanel from plone.app.controlpanel, etc.).

I expect this PLIP to be ready in Q1, 2012.