I think it is time to differentiate generic extractors from calendar related extractors; there are several refactoring opportunities.
As a first step, I propose removing event specific stuff from the Extractor class to a new EventExtractor class to be used in Exams, Bills, Moodle, etc. For example, the methods getName, getDescription. Furthermore, all EventExtractors have a storage property isHTML by default to indicate whether the name and description are HTML or plaintext.
I also think it is time to create a proper class for a calendar event. The concept of event object is used in several modules (extractors, utils, modal, etc), and it is often confusing what properties that object has (all have common properties, like a starting/ending time and location, but has additional stuff that depends on the extractors, so it is confusing). Besides, the event title and description are retrieved as ExtractorInstance.getName(eventObject);. Which forces us to move the extractor instances around as each extractor has its own format for calendar event's title and descriptions. For instance, consider the exams extractor. In order to attach the button that opens the modal with all exams, it calls the global function handleEvents which receives the extractor itself and an array of event objects.
I think it would be OK to separate concerns. Utils functions that prepare the modal with events don't need to know about the extractor if they have a list of Events instances with pre-formatted titles and descriptions. Regardless of the extractor, a calendar event will always have a start & end time, a location, and the recurrence can be induced, and that information is sufficient to create the UI components and can be re-used in other extractors besides the exams one.
I think it is time to differentiate generic extractors from calendar related extractors; there are several refactoring opportunities.
As a first step, I propose removing event specific stuff from the
Extractorclass to a newEventExtractorclass to be used in Exams, Bills, Moodle, etc. For example, the methodsgetName,getDescription. Furthermore, allEventExtractorshave a storage propertyisHTMLby default to indicate whether the name and description are HTML or plaintext.I also think it is time to create a proper class for a calendar event. The concept of event object is used in several modules (extractors, utils, modal, etc), and it is often confusing what properties that object has (all have common properties, like a starting/ending time and location, but has additional stuff that depends on the extractors, so it is confusing). Besides, the event title and description are retrieved as
ExtractorInstance.getName(eventObject);. Which forces us to move the extractor instances around as each extractor has its own format for calendar event's title and descriptions. For instance, consider the exams extractor. In order to attach the button that opens the modal with all exams, it calls the global functionhandleEventswhich receives the extractor itself and an array of event objects. I think it would be OK to separate concerns. Utils functions that prepare the modal with events don't need to know about the extractor if they have a list of Events instances with pre-formatted titles and descriptions. Regardless of the extractor, a calendar event will always have a start & end time, a location, and the recurrence can be induced, and that information is sufficient to create the UI components and can be re-used in other extractors besides the exams one.