CPSDefault should not depend on CMFCalendar

Apparently getCalCPSDayViewParams is called at least by source:CPSSkins/trunk/skins/cpsskins_cps3/cpsskins_getCalendar.py and source:CPSBoxes/trunk/skins/cps_boxes/boxes_nuxeo.pt

So, the feature that is really needed is to make boxes/portlets support both CPSSharedCalendar and CPSCalendar (which in turn uses CMFCalendar), and not complain when none of these are installed.

More information:

The CPSSkins calendar template currently gets installed if there is a portal_calendar object, but it is not compatible with CPSSharedCalendars tool. I have started work on that.

The CPSDefault patching and skins can be moved to CPSCalendar.

We no longer use the name portal_calendar for a tool. The import and patching of CMFCalendar can be made optional.

However, with the new profiles, it doesn't seem possible to install the CPSSkins calendar portlet at all. That may be just as well, as CPSSharedCalendar has a portlet now, it might be confusing to have two.

CPSDefault no longer *depends* on CMFCalendar, but CPSDefault currently includes three files that use the portal_calendar tool, if it exists.

• source:CPS3/products/CPSDefault/trunk/CMFCalendarToolPatch.py
• source:CPS3/products/CPSDefault/trunk/skins/cps_default/calendar_cpsday_view.pt
• source:CPS3/products/CPSDefault/trunk/skins/cps_default/getCalCPSDayViewParams.py

The CMFCalendarToolPatch patches in new methods on the tool, to support the use of CPS Event documents for the CMF calendaring. These methods are used by the other two skins, which in turn seem unused. The patched methods is also used by the calendar templet in CPSSkins. This templet was installed in CPS 3.3 if you had a portal_calendar tool. In CPS 3.4 it goes unused.

I suggest that we deprecate the calendar template. If we still want to support CMF Calendaring in CPS Jean-Marc sais he would prefer a portlet (in CPSPortlets I assume).