Refactor datatype festival #133

New issue

Open

opened 2018-11-26 12:17:20 +00:00 by giplt · 2 comments

giplt commented

2018-11-26 12:17:20 +00:00

(Migrated from github.com)

The datatype festival could be a lot easier once the datatype event (#131) is implemented.

matthijskooijman commented

2020-08-24 14:47:51 +00:00

(Migrated from github.com)

    <page id="5cf806dfd2661" type="festivalpage">                              
      <language id="en" name="festival2019"/>                                  
      <page id="5cf806dfd2661" type="event"/>                                  
    </page>

Then the festival page XML will refer to the event page id for each contribution.

Having separate page XML for contribution events would probably simplify translation and versioning for events as well (#335).

To allow customizing display or derive attributes for certain kinds of events, a "subtype" approach might be useful, where there is e.g. a festival_contribution_event or agenda_event which is a subclass of event and can override some methods (and maybe also add subtype-specific methods and fields). Such a subtype could just be the type="..." value in the hypha.xml, but that would somewhat complicate querying "give me all events" (though with some reflection, getting a list of all datatypes that extend the event base type is certainly possible). Maybe adding a subtype (or something implements="event") could make querying easier (but that does essentially duplicate the PHP class inheritance info in the XML).

Open question: Where to store the extra data? E.g. "Notes for the organizers" is not an event property, but only exists for festival contributions. Do we store that in the festival XML, along with the reference to the event page id? Or inside the event page XML as an "extra" attribute/tag (i.e. not interpreted by code that looks at any event, but interpreted by the festival module)? Storing it inside the event XML could help to include the property in the translation / versioning structure (though for this particular "notes for the organizers", this would not need to be translated, maybe only versioned).

Such an "event" page type, when used as part of a festival, should probably not get its own url in the root namespace (like normal pages), but instead only exist "inside" the festival page (where the festival page is responsible for routing requests to the event and/or processes requests itself). This still allows getting a list of all "event" pages if you query recursively. ``` <page id="5cf806dfd2661" type="festivalpage"> <language id="en" name="festival2019"/> <page id="5cf806dfd2661" type="event"/> </page> ``` Then the festival page XML will refer to the event page id for each contribution. Having separate page XML for contribution events would probably simplify translation and versioning for events as well (#335). To allow customizing display or derive attributes for certain kinds of events, a "subtype" approach might be useful, where there is e.g. a `festival_contribution_event` or `agenda_event` which is a subclass of `event` and can override some methods (and maybe also add subtype-specific methods and fields). Such a subtype could just be the `type="..."` value in the hypha.xml, but that would somewhat complicate querying "give me all events" (though with some reflection, getting a list of all datatypes that extend the `event` base type is certainly possible). Maybe adding a `subtype` (or something `implements="event"`) could make querying easier (but that does essentially duplicate the PHP class inheritance info in the XML). Open question: Where to store the extra data? E.g. "Notes for the organizers" is not an event property, but only exists for festival contributions. Do we store that in the festival XML, along with the reference to the event page id? Or inside the event page XML as an "extra" attribute/tag (i.e. not interpreted by code that looks at any event, but interpreted by the festival module)? Storing it inside the event XML could help to include the property in the translation / versioning structure (though for this particular "notes for the organizers", this would not need to be translated, maybe only versioned).

giplt commented

2020-08-24 15:41:54 +00:00

(Migrated from github.com)

I would put the extra field(s) in the festival XML as they apply specifically to the context of the festival and need no translation.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

harmen/hypha#133

No description provided.

Rows
Columns