CalendarFilterState.kt
CalendarFilterState records transient view-state information that is persisted per user, so that when returning to the calendar the user sees the same date range and view type they last used. It stores the last-viewed start date and the active CalendarView (month, week, day, etc.). Uses XStream @XStreamAsAttribute annotations for serialization.
| Field | Type | Default | Annotation | Description |
|---|---|---|---|---|
startDate |
LocalDate? |
null |
@XStreamAsAttribute |
The first date of the calendar range the user last viewed. Determines which month/week/day is displayed on return. |
view |
CalendarView? |
null |
@XStreamAsAttribute |
The last selected calendar view mode (e.g., MONTH, WEEK, DAY). Null indicates default view. |
The commented-out firstHour and slot30 fields indicate these settings were moved to CalendarFilter during refactoring but kept as documentation artifacts.
This is a simple data class instantiated by the calendar system when persisting or restoring user state. It does not contain business logic. It is typically serialized via XStream (the legacy persistence mechanism) into a user preferences XML entry. The @XStreamAsAttribute annotations cause the fields to be serialized as XML attributes rather than child elements, keeping the persisted XML compact.
Separating view-state (CalendarFilterState) from filter configuration (CalendarFilter) follows the single-responsibility principle. Filter configuration changes the content of the calendar (which calendars, what timesheet user, etc.), while state captures the ephemeral navigation position. Keeping them separate avoids polluting the favorites comparison logic (isModified() in CalendarFilter) with transient view-position data, so that simply scrolling to a different month does not mark the filter as "modified."