RFC: Split CalendarEvent / CalendarDateTime into its own "base" module and keep additional nuts & bolts as another module

[silbinarywolf]

My thinking is, data-wise, the CalendarEvent / CalendarDateTime models are reasonably simple and have decent defaults.

Perhaps by moving just those to a "event-calendar-core" module or something.

This thought came about because the more we're able to break this module up into pieces, theoretically we can upgrade it to SS4 in a piecemeal fashion.

[unclecheese]

I assume you would include Calendar in that group, as well? Yeah, makes sense to me. It certainly aligns with the goals and principles we've laid out in SS4 for smaller, more interoperable modules.

Just off first glance, we'd be looking at:

• CalendarWidget
• ICSFeed/iCal
• Caching task
• Recurring events?
• Announcements?

[OliverBanjo]

CalendarDateTime class could be divided with lower-level functionality, defaults and just the $db properties in a BaseDateTime. Maybe this could be bundled into a DateTimeUtility module!

My thinking was Calendar/CalendarEvent/CalendarDateTime are quite bound to each other for the application of the calendar page and so may remain together. CalendarDateTime and CalendarEvent can then implement interfaces for their requirements.

• recurring events? Seems quite integrated. I was expecting to find a RecurringDateTime.
• Announcements? I think I see the light.

Certainly there are gems in this module which can shine on their own.

[OliverBanjo]

I created a pull request (#143 ) to demonstrate the above idea as a first step. I took the liberty to name the super/base class EventDateTime. It would be a breaking change if introduced so included a reversible task with MySQL operations to migrate the data and reflect the change in the model. Maybe there is an appropriate way the task could run without the user being aware!