#868: ICalendarEvent.kt

projectforge-business/src/main/kotlin/org/projectforge/business/calendar/event/model/ICalendarEvent.kt Type: Kotlin interface
Purpose: Common contract for all calendar event implementations across calendar types
Source path: projectforge-business/src/main/kotlin/org/projectforge/business/calendar/event/model/ICalendarEvent.kt 45 lines · 11 code · 25 comments · 9 blank

ICalendarEvent defines the minimal set of properties that any calendar event in the ProjectForge system must expose. This interface allows different event types (team calendar events, timesheet entries, vacation entries, birthdays) to be handled uniformly by calendar rendering and filtering code. It was originally a Java class (TeamEvent.java) and was converted to a Kotlin interface during the modernization effort.

Interface Properties

PropertyTypeDescription
uid String? Unique identifier for the event. Can be nullable to accommodate event types without native UIDs.
subject String? The event title or subject line. Displayed as the primary text in the calendar.
location String? Physical or virtual location of the event. Nullable for events without a location.
allDay Boolean Whether the event spans an entire day (or multiple full days). Affects rendering (no time slots).
startDate Date? The start date and time of the event (legacy java.util.Date). Nullable to support edge cases.
endDate Date? The end date and time of the event. Nullable — some implementations may infer duration from startDate.
note String? Optional description or note text. Shown in tooltips and detail views.

Architecture

This interface serves as a common denominator across event sources:

By coding calendar rendering and filtering against ICalendarEvent rather than a concrete class, the system achieves polymorphism across these disparate event sources without requiring a common base class or database table.

Git History

Design Rationale

Converting the original Java class TeamEvent to a Kotlin interface (ICalendarEvent) was a key architectural improvement (commit aab28d48a). A concrete class implied a single implementation with shared state; an interface allows each event type to own its data structure independently while still being treated polymorphically by calendar code. The java.util.Date type (rather than java.time) persists because many implementors are JPA entities backed by Date database columns. The extensive use of nullable types reflects the reality of partial event data (e.g., an all-day event may have no meaningful start/end time, a birthday has no location).