Aller au contenu. | Aller à la navigation

Outils personnels


Vous êtes ici : Accueil / Articles / Plone Cathedral Sprint Calendaring Team Report

Plone Cathedral Sprint Calendaring Team Report

Par Vincent Fretin publié 28/03/2010 17:12, Dernière modification 28/03/2010 17:12
Some details about how to use the new calendar widget in your project.

I was in Cologne for the Plone Cathedral sprint (15-19 march 2010). I'm a bit late for a summary, Andreas Jung already did it. See Plone Cathedral sprint after-action report for a report of the other teams.

So here I will focus on what I actually did with the new calendar widget.

If you didn't see the screencast yet, please view it now.

If you want to test it by yourself, get the Plone 4.0 branch as usual:

svn co plone4
cd plone 4

and run this specific buildout configuration:

bin/buildout -c plips/plip9302-vs-event-integration.cfg

Start the instance, and apply the profile at the Plone Site creation.

We extracted the ATEvent content type from Products.ATContentTypes/Plone and created the package. It's the same idea as, etc.

The new package depends on collective.calendarwidget for the new Archetypes calendar widget which is based on the datepicker jqueryui plugin. The collective.calendarwidget package depends itself on collective.js.jqueryui to install the jqueryui library. So collective.js.jqueryui <- collective.calendarwidget <-


Lots of packages already use collective.js.jqueryui to install jqueryui on Plone. The idea is to not include the jqueryui library in each package that needs it! I updated the package (in trunk) to include jqueryui 1.8rc3, latest version compatible with jQuery 1.4+. So this version works only on Plone >= 4.0. I wrote a viewlet which set the datepicker language according to the user preferred language and set explicitly the date format.

The date format can be "dd/mm/yy" (French), "mm/dd/yy" (English) or "" (German) for example. This is what you see in the input field in the browser.

When you send the form, the server needs to know the date format to be able to parse the date string and create a datetime/DateTime object. This is why the date format is set explicitly on the server side when configuring the datepicker plugin. So we know how to parse the date string afterwards.

The date format used is the date_format_short_datepicker msgid in the plonelocales domain in the package. So you can choose another format if you want.

The package contains some utils to parse the date string sent by a form.

You can use this package alone in a simple view. Here a simple example:

<html xmlns="" xml:lang="en"

<metal:js fill-slot="javascript_head_slot">
<script type="text/javascript">
  jQuery(document).ready(function() {

<metal:main fill-slot="main">
<form action="@@myview">
  <input type="text"
  <input type="submit" value="Submit" />


and to retrieve the date, you can use:

from collective.js.jqueryui.utils import get_python_date_format, parse_date
import datetime

datestr = self.request.form.get('date')
date_format = get_python_date_format(self.request)
ymd = parse_date(datestr, date_format)
date =*ymd)


This is the new Archetypes calendar widget. It's using the jquerui datepicker, so it depends on collective.js.jqueryui. You can use it on your own content types in Plone >= 4.0.

You can just simply replace the old import:

from Products.Archetypes.atapi import CalendarWidget


from collective.calendarwidget.widget import CalendarWidget

You can add the with_time=1 parameter if you want a datetime widget.

Here is the startDate field from as an example:

                  label=_(u'label_event_start', default=u'Event Starts'),
                  )), is a new package for Plone 4.1. The ATEvent content type has been moved from Products.ATContentTypes to this new package. It adds a wholeDay field, uses the new calendar widget and now use by default a 1 hour interval between the start and end time. You have some JS functions that help you when choosing a date.

  • When you choose a start date, the end date is updated to keep the previous interval between the two dates.
  • When the wholeDay field is checked, the times are hidden.
  • If you select and end date inferior to the start date, the end date becomesred.

Johannes Raggam worked on the recurring event implementation, this is a work-in-progress. This new package depends now on Products.DateRecurringIndex. The end and start indexes in portal_catalog, which were using the DateIndex now use this new implementation. We can for the moment include raw recurring rules. We need a UI to set the rules and we need to update the calendar portlet or create another calendar view which support the recurring events.