[PLIP-Advisories] [Plone development workspace] #10886: plone.app.event - new eventtype for plone
Change notifications for Plone PLIPs on Trac.
plone-plip-advisories at lists.plone.org
Fri Oct 21 19:51:49 UTC 2011
#10886: plone.app.event - new eventtype for plone
------------------------------------+-------------------
Reporter: thet | Owner: thet
Type: PLIP | Status: new
Priority: minor | Milestone: 4.3
Component: Infrastructure | Resolution:
Keywords: event, recurring, date |
------------------------------------+-------------------
Description changed by thet:
Old description:
> '''Proposer:''' Johannes Raggam[[BR]]
> '''Seconder:''' None as yet[[BR]]
> [[BR]]
> 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
>
> Please note: this PLIP is an update of
> http://dev.plone.org/plone/ticket/9302
>
> [[BR]]
> == Motivation ==
> The current event type is in need of a major overhaul. The datetime
> widgets are hard to use, and makes it hard to enter such things as all
> day events. Recurrence is a recurring feature request, that has been
> solved many times.
>
> == Proposal & Implementation ==
> At the cathedral sprint in cologne a new package was created named
> plone.app.event [1]. It is based on the work from vs.event [2].
>
> The intention of plone.app.event is to provide an improved event type for
> plone. It should be a replacement of ATEvent. All event specific code is
> peeled out of ATContentTypes and refactored into plone.app.event, as it
> was done with plone's folder implementation (plone.folder and
> plone.app.folder). Benefits of separating the most complex ATContentType
> from ATCT could be:
> * Easier maintaining of the event content type
> * Easier to reuse generic calendaring tools (Generalizing them
> eventually in plone.event)
> * Possibility to use plone.app.event also as a basis for a dexterity
> event type implementation
>
> Features of plone.app.event:
> * drop-in replacement for ATEvent
> * new calendar widget with full internationalization and localization
> support (collective.calendarwidget [3])
> * support for whole day events
> * support for events without end dates
> * proper export of whole day events to iCal
> * recurrence
>
> plone.app.event provides an ATEvent content type which implements
> IATEvent. IATEvent should be based on a more generic IEvent interface.
> This should then also be the basis for eventtype implementations based on
> dexterity.
>
> The implementation of the recurrence support started at the cathedral
> sprint could be done as follows:
> Products.DateRecurringIndex is a drop-in replacement for the standard
> DateIndex. When the event type is being indexed, it should calculate
> every occurrence for the start-date and the end-date based on recurrence
> definition rules and write it to the start- respectively the end-index.
> The original version has support for recurrence rules based on time-
> deltas. The improved version of Products.DateRecurringIndex [4] has
> additional support for dateutil's recurrence rules. Dateutils[5] rrule is
> a complete and fast implementation of the recurrence rules defined in the
> iCalendar RFC [6].
> The event type should make use of a recurrence field and a recurrence
> widget, possibly based on archetypes.recurringdate [7]. In combination
> with dateutil, the power of the recurrence support is more or less just a
> question of the recurrence widget.
>
> The pytz library for timezone conversation related things should be used
> where possible and appropriate.
>
> Some architectural decisions aspects need still to be discussed.
>
> == Deliverables ==
>
> * Products.ATContentTypes branch without it's event related code
> * collective.calendarwidget for a date selecting widget
> * plone.app.event for the content type and all event related code
> remaining
> * tests, documentation, localization of course
>
> For recurrence support:
> * Products.DateRecurringIndex with dateutil support
> * An updated Calendar portlet that uses the recurrence index (best
> place for it: plone.app.event).
> * Updated content views.
> * archetypes.recurringdate for a recurrence field which stores
> recurrence definitions or datetuils.rrule instances itself and widget
> which provides fields to define the recurrence definitions
> * a migration step to re-index all events, using
> Products.DateRecurringIndex
>
> == Risks ==
>
> * plone.app.event and Products.ATContentTypes must be synchronized
> sometime
> * Event related code must be removed from Products.ATContentTypes
> sometime
> * Third party packages which rely on ATCT internals may break
> (although ATCT should still provide BBB imports from plone.app.event)
>
> == Participants ==
>
> * Johannes Raggam - Products.DateRecurringIndex, recurrence related
> work
> * Vincent Fretin - collective.calendarwidget
>
> Unconfirmed, but cologne plone.app.event sprint participants:
> * Andreas Jung - vs.event refactoring to plone.app.event
> * Tom Gross, Rodrigo Ristow - plone.app.event,
> Products.ATContentTypes
>
> == Progress ==
> * collective.calendarwidget: almost done
> * plone.app.event: Half Way. Currently based on:
> Products.ATContentTypes 2.0b10
> * Products.DateRecurringIndex: First working version done at
> cathedral sprint [4]. Currently under refactoring [8]
> * archetypes.recurringdate: Was started by "deo" at ploneconf2009. It
> has to be refactored to fit into plone.app.event,
> collective.calendarwidget and Products.DateRecurringIndex
>
> == Links ==
> [1] http://pypi.python.org/pypi/vs.event
>
> [2] https://svn.plone.org/svn/plone/plone.app.event
>
> [3] https://svn.plone.org/svn/collective/collective.calendarwidget
>
> [4] https://svn.plone.org/svn/collective/Product
> s.DateRecurringIndex/branches/DateRecurringIndex2-dateutils
>
> [5] http://labix.org/python-dateutil
>
> [6] http://www.ietf.org/rfc/rfc2445.txt
>
> [7]
> https://svn.plone.org/svn/archetypes/MoreFieldsAndWidgets/archetypes.recurringdate/
>
> [8] http://github.com/thet/Products.DateRecurringIndex
New description:
'''Proposer:''' Johannes Raggam[[BR]]
'''Seconder:''' None as yet[[BR]]
[[BR]]
== 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
--
--
Ticket URL: <http://dev.plone.org/ticket/10886#comment:41>
Plone development workspace <http://dev.plone.org/>
Plone Enterprise Content Management System
More information about the PLIP-Advisories
mailing list