collective / icalendar

icalendar parser library for Python

Home Page:https://icalendar.readthedocs.io/en/latest/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Clarify how custom components should be parsed

angatha opened this issue · comments

This issue arises from #417. See that PR for more context.

The test case from #417 uses icalendar.Calendar.from_ical(...) to parse a custom component. As for now (#417), that method is an effectively static class method. (It is a class method but doesn't use the cls argument.) It uses an instance of icalendar.cal.ComponentFactory to determine the class that represents the component, defaulting to icalendar.cal.Component.

What is the correct way of parsing a custom component?

Doing the analog of the current behavior, is one option. Calendar doesn't redefine from_ical(...) so actually the call is equivalent to icalendar.cal.Component.from_ical(...). A second option would be to model custom components with two new types. (Be welcome to add other solutions)

  • Use icalendar.cal.Component.from_ical(...) directly.
  • Introduce an XComponent and an IanaComponent (See RFC 5545)

Since currently there is no difference between icalendar.Calendar.from_ical(...) and icalendar.cal.Component.from_ical(...) when parsing an VCALENDAR (and other components), is it a feature, that they could be used interchangeable, is it a bug, that they don't validate the type or is it just undefined behavior when relying on the behavior of icalendar.Calendar.from_ical(...)? That should be clarified when documenting the new components (if that solution is chosen) but also it may be something to add for other components.

Steps to take

  1. clarify the questions from above
  2. implement chosen solution
  3. potentially adjust tests extracted from #433