Now with plone.app.theming we are in the lucky situation to deliver really any design with Plone.

But there are also designers out in the wild creating designs not compatible with Plones edit-mode.

So its sometimes easier to edit in the classic Plone UI (Sunburst Theme) using a different web address for editing.

And here is how to do it:

1. Consider to configure two adresses http://edit.domain.tld and http://www.domain.tld 
2. Add a subscriber to zope.app.publication.interfaces.IBeforeTraverseEvent to configure.zcml
   

   <configure ...
   ...
     <subscriber
       for="* zope.app.publication.interfaces.IBeforeTraverseEvent"
       handler=".subscriber.surpress_theme"
     />
   </configure>

3. Add a file subscriber.py with code to conditionally set the header X-Theme-Disabled: True  in case of edit domain (you may want to improve the condition).
   

   def surpress_theme(obj, event):
       if event.request['ACTUAL_URL'].startswith('http://edit.'):
           event.request.response.setHeader('X-Theme-Disabled', 'True')

4. Restart your instance

To test this on localhost just add something like edit.localhost to your /etc/hosts file for 127.0.0.1 and enter http://edit.localhost/Plone in your browser.

Image by karlbirrane at flickr under a CC-BY-SA license

Shortly after Plone 4.2 feature freeze announcement, we - Rok Garbas and Johannes Raggam - met up to bring plone.app.event [1] forward and see what's missing to be submitted for the next Plone release. Well, we didn't catch the deadline, but did some amazing work which will ultimately lead in a better event implementation.

Rok and me met up on a sunny Saturday morning in Ljubljana. Since there was no hacker space available to be opened on this weekend - people were on the seaside, which was actually a very good idea - we developed a new sprint-style: bar-driven development. We started in a cafe, discussed all TODOs and began to work on the first couple of tasks. Before we closed the sprint 26 hours later, we have been in 4 more bars, excluding those we visited without our laptops [2]. Our only need was free WIFI, power plugs, cafe and drinks. That worked out very well and was fun too!

Plone.app.event was started at the cologne sprint in march 2010 [3], building upon previous work like vs.event, Dateable, Kalends and Products.DateRecurringIndex. Now, while discussing the left over TODOs from the Artsprint 2011 in Vienna [4], we rethought some design decisions and came to the conclusion, that refactoring of all involved packages is what we need in order to meet plone.app.event's initial goals: An encapsulated and independent [a], archetypes and dexterity aware [b], standards compliant [c], event implementation with support of recurrence [d], a modern dateinput widget [e], with features like whole-day-events [f] and proper timezone support [g].

Encapsulation and Independence

To meet the goal [a] - encapsulation, we moved as much as possible event related code out from the packages Products.CMFCore, plone.app.portlets and Products.ATContentTypes into plone.app.event [5] and plone.rfc5545 [6] (formerly plone.event). Event the catalog index registration via Generic Setup was moved out of Products.CMFCore into plone.app.event, since it's only needed if there are eventish content types with and start and end dates available. The goal is also to remove the dependency of Products.CMFCalendar, which functionality should be provided by plone.app.event then.

Archetypes and Dexterity aware

To support archetypes and at the same time dexterity [b], we factored out generic code into reusable modules. Plone.rfc5545 is generic without dependencies to the Plone core and can thus be used independently of Plone. All Archetypes related code is encapsulated in a submodule of plone.app.event respectively plone.formwidget.dateinput. A dexterity content type is yet not available, but will be provided sometime soon.

Standards compliancy

The standards involved [c] covers compliance with the iCalendar standard - also known as RFC5545 [7], which obsoletes RFC2445. Rok started to create an RFC compatible serializer which utilizes the Zope's component architecture in a very smart way. An deserializer can later be added. This might lead sometime into a (Attention: Utopia!) caldav server which is able to handle subscriptions from calendar clients like Apples iCal or Mozillas Sunbird. Zope even provides an webdav interface, so we can build upon a stable infrastructure. Imagine the awesome capabilities if Plone provides such a functionality!

Recurrence support

The recurrence support [d] is build upon the library python-dateutil [8], which itself is RFC2445 compliant. The difference to RFC5545 is mostly, that RFC5545 does not allow (respectively should not use) more than one recurrence rule definitions and removes the ability to define exclusion rule sets. The library handles the calculations of occurrences of an event and can parse RFC compatible recurrence strings directly. There is also an index, which handles recurring dates - the package Products.DateRecurringIndex [9]. It is production ready and works as a direct and transparent replacement of Zope's DateIndex. If you query for events on a specific date, it will return also Events, which do not have their start date but a recurrence on the queried date. If you need all occurrences of an specific event, you have to use a method on this recurrence-enabled event to get it. The possibility to query the index for that is - yet - not available. Lennart Regebro, who is also a specialist on recurring events, delivered another index for that purpose - the plone.app.eventindex [10]. It does lazy indexing on query time and is an very interesting alternative. Anyway, the discussion about indexing recurring events flared up and some open questions regarding indexing performance and meaningful benchmarks - as well as an still to be polished recurrence input widget [11] - are the reasons why here is still some more work to do.

Dateinput widget

[e] Plone's current dateinput widget has come into its days. There are fresher JQuery based alternatives available, especially the JQueryUI Datepicker [12] and the JQueryTools Dateinput [13]. Since Plone uses JQueryTools we are using the Datepicker. We developed the package archetypes.datetimewidget as a fork of collective.z3cforms.datetimewidget. Those packages share a lot of common functionality, so we merged them into plone.app.dateinput [14]. It's on it's way.

Whole-day events

Plone.app.event will support whole-day events [f]. Not a big deal, but very convenient. Whole-day events are still stored with a time component, which for the start field is set to 0:00 and for the end field to 23:59. The time component is hidden per JavaScript when selecting the whole-day checkbox.

Timezone support

And finally Timezones [g]: Proper timezone support was long missing in Plone, it's planned to land in the 4.x series. With plone.app.event, we can set the Portal's default timezone, a timezone for a specific event (the options are limited through an available timezones property in plone.app.registry), and eventually timezones per user. UTC serves as our reference timezone and all dates are stored in UTC, while the timezone is stored in a separate field. This makes handling of timezones and converting to different zones for display much more predictable, since UTC is not subject to change. Internally we rely on the pytz library instead of Zope-DateTime's own implementation. Pytz [15] is a python implementation of the Olson Database [16], which is updated several times a year. Proper timezone support is necessary, especially for recurring events over Daylight Saving Time changes, where it's necessary to know if or if not a additional offset has to be added. It's mostly implemented except the support of user timezones.

What next?

If you want to try everything out, i suggest to use out the pre-refactored implementation from plone-svn [17]. If you want to try out and test the refactored cutting edge development version, go for this one: [5]. Run buildout, run the tests, start the instance (at least for the pre-refactored version) and start playing.

Vincent Fretin uses the pre-refactored implementation in production. We are now in a state, where the conceptional refactoring and migration to plone.app.testing as base test infrastructure is almost done. We have to get all refactored packages work again and fix all failing tests. The recurrence widget has to be polished and brought into a workable state, including javascript tests. The recurrence indexes have to be benchmarked and further developed. There is still some more work TODO, as you can see here [18].

So come and join in, help with finding and/or fixing bugs, install and test it. Or maybe finance a sprint or the development itself, if you are in need of a working event content type and framework implementation, that might be superior to any calendaring application ever seen on this planet ;).

Contact

For more information contact:

Johannes Raggam <johannes@raggam.co.at>
Rok Garbas <rok.garbas@gmail.com>
Vincent Fretin <vincent.fretin@gmail.com>
BlueDynamics Alliance <dev@bluedynamics.com>

Or one of the contributors listed here [19].

References

• [1] http://dev.plone.org/plone/ticket/10886
• [2] http://en.wikipedia.org/wiki/Metelkova
• [3] http://www.zopyx.de/blog/plone.app.event
• [4] http://www.coactivate.org/projects/artsprint2011
• [5] https://github.com/collective/plone.app.event
• [6] https://github.com/collective/plone.rfc5545
• [7] http://tools.ietf.org/html/rfc5545
• [8] http://labix.org/python-dateutil
• [9] https://github.com/collective/Products.DateRecurringIndex
• [10] http://svn.plone.org/svn/collective/plone.app.eventindex/trunk/
• [11] https://github.com/collective/plone.formwidget.recurrence
• [12] http://jqueryui.com/demos/datepicker/
• [13] http://flowplayer.org/tools/demos/dateinput/index.html
• [14] https://github.com/collective/plone.formwidget.dateinput
• [15] http://pypi.python.org/pypi/pytz/
• [16] http://en.wikipedia.org/wiki/Tz_database
• [17] https://svn.plone.org/svn/plone/plone.app.event/trunk/
• [18] https://github.com/collective/plone.app.event/blob/master/TODO.rst
• [19] https://github.com/collective/plone.app.event/blob/master/README.txt

Heute ist der IT-Day der Wirtschaftkammer Fachgruppe UBIT und der Standortagentur Tirol.

Klein & Partner hat einen Stand und steht für Ihre Fragen zur Verfügung.

Plone Foundation happily got five slots for Google Summer of Code 2011 projects. Two of the committed proposals refered to software related to the BlueDynamics Alliance.

Dexterity type modelling and generation

First the ArchGenXML successor, a complete rewrite called AGX, was proposed to get extended to generate Dexterity content-types. Proposing student for this project is Pranshu Saxena, third year student of Computer Science at Birla Institute of Technology and Science (BITS), Pilani, India. Mentor is Robert Niederreiter from Austria, main contributor of the new AGX stack. Co-mentor Jens Klein is long term contributor to both, ArchGenXML and AGX, supporting this project with deep knowledge in UML. Phil Auersperg, original author of ArchGenXML, known for his "lazy-programming" aproaches, will help to develop KISS-style and usable model-profiles and testing.

Stanbol Semantic Enhancement Engine

Second proposal deals with semantic web, using the Apache Stanbol stack of the IKS project where BlueDynamics Alliance acts as Early Adopter for FISE-Plone Integration and is involved in the project as community partner. Proposing student is Yannis Mazzer, fourth year student in the computer science department of the University Claude Bernard of Lyon in France. Mentor is Jens Klein, involved in IKS from pre-alpha release of FISE, the sementic enhancement engine. He participated in three IKS community workshops.

Proud to support Plone

In our long tradition of participating in the Plone Community and contributing to OpenSource we thanks Google to advance young software engineers. Thumbs up on the Plone Community for it's huge engagement in always bringing Plone towards the next level.

On behalf of Gogo I take the opportunity to announce here the artSprint ]a[ 2010 to be held at the academy of fine arts in vienna. Any topic from Python over art to rocket science is welcome.

Currently planned are topics in the cloud of Python, UML, node-trees, HTML-forms with YAFOWIL, Pyramid, recurring events in Plone, we may start an Arduino microcontroller playground (beginners level), small art exhibition and if you have an idea -> come and bring it with you.

When? January the 31st (Monday) to February the 4th (Friday).

More Information? -> http://www.coactivate.org/projects/artsprint2011 - Join us!