Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor the modelling of date time field setting to be consistent with RFC5545 #7

Open
CXwudi opened this issue Jan 6, 2023 · 2 comments
Assignees

Comments

@CXwudi
Copy link
Owner

CXwudi commented Jan 6, 2023

Currently we are using our own model but it is actually quite annoying and hard to model it.

Why not just use whatever RFC5545's VEvent defined. In summary, a VEvent can have:

  1. date type start
  2. date type start + day/week-wise duration (allow users to set a default duration with # of days)
  3. date type start + date type end
  4. Date time type start + Date time type end
  5. Date time type start + duration (allow users to set a default duration)

Then, the 5 types can also to mapped to 3 different EventType:

1. one day event
2. multi-day event
3. datetime event

So this lead to 3 settable fields: DtStart, DtEnd, and Duration.

Since DtEnd and Duration are both related to the end date, we could group these two into one sealed interface.

Since we also want to support have fallbacks for some fields if one field value is missing (this can be only applicable at the same type of event), and we also want to support #9 . Hence, the new modelling would be following:

  1. make ToBeMappedYouTrackIssueInfo a normal data class, and it contains a list of instances of DateTimeFieldInfo. (solve Let cliapp support mapping to different type of VEvent #9)
  2. The DateTimeFieldInfo would also be a normal data class with the following fields:
    1. An enum field determining is the event is date or datetime type:
    2. An start datetime field
    3. A list of instances of a sealed interface called maybe EndDateTimeFieldInfo. (see explanation below)
    4. A list of AlarmSetting. (see Refactor the modelling of the alarm setting to be consistent with RFC5545 #8)
      The first two fields identify the DateTimeFieldInfo instance.
  3. EndDateTimeFieldInfo simply have 3 subclasses of
    1. uses a dedicated end datetime field from YouTrack issue
    2. uses a dedicated duration field from YouTrack issue, with asking to be negative or positive
    3. uses a fixed duration
  4. EndDateTimeFieldInfo is used for representing a multi-day event and datetime event. If the list is empty, it means no end datetime = a whole day event. The order of the list representing the attempt to create end date time or duration.
    1. e.g. The ToBeMappedYouTrackIssueInfo can contain all 3 types of EndDateTimeFieldInfo in the list. And the 3rd option "uses a fixed duration" can be the backout option if both the end datetime field and duration field is unavailable in a YouTrack issue
    2. However, if all attempts from the list is failed (e.g. a non-empty list without the "uses a fixed duration" EndDateTimeFieldInfo and all fields in that list failed to get value), then this should be traded as hard mapping failure (same level failure as missing start date), because mapping it to a whole day event may cause confusion. (or maybe we can make it a configurable setting)
@CXwudi CXwudi self-assigned this Jan 6, 2023
@CXwudi CXwudi changed the title Refactor the modelling of date time field setting to be consistent with RFC5455 Refactor the modelling of date time field setting to be consistent with RFC5545 Jan 6, 2023
@CXwudi
Copy link
Owner Author

CXwudi commented Jan 10, 2023

The following image can summarize the structure of this issue, #8 and #9:

image

@CXwudi
Copy link
Owner Author

CXwudi commented May 8, 2023

Implementation step (in ical-core module only, in a separated branch):

  1. rename all existing models to old
  2. comment out the part where core function is called in cliapp
  3. start adding new models
  4. let all core functions using new model

Then modify cliapp's configuratioin structure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Todo
Development

No branches or pull requests

1 participant