Activity redesign ARCHIVED

Goal

The main goal of the redesign of the activity module is to improve maintainability and reduce the amount of unnecessary duplication, in particular. This redesign should in principle not change any functionality, but make it easier to create other functionality later on, such as issues #801 (could use a better method for translations) or #749+#732 (need to add a field to the activity model, which currently is far more complicated than it should be).

Model

Below is a class diagram of the new models for the activity module.

The main changes are:

• Activity has been split into an Activity, containing the data of the actual activity and a SignupList, containing the data of a possible subscription list.
• Fields that have a language associated with them, such as name and nameEN, are replaced by a single field of the class LocalisedText. The advantage of this change is that translations can be mostly ignored in the Service or Controller, reducing the complexity and repetition that currently results from handling translations in those places. The translation is done in the activity model, so e.g. $activity->getName() will (by default) directly return a string and not a LocalisedText object. The method setLanguage(lang) will be used to toggle the behaviour of these calls. There are four options:

1. Preference for the language indicated by the current locale (this is the default setting)
2. Preference for the English field
3. Preference for the Dutch field
4. Return the actual LocalisedText object. (useful for admin approval)

• The boolean flags associated with the Activity model can be replaced by a list of 'categories'. These categories function similar to tags, i.e. an Activity can have multiple categories and there is no specific relation between the categories.

• Could have: multiple subscription lists and subscription lists without activities (these will be unlisted). A use-case for multiple subscription lists is when there are two lists for different types of subscriptions, where one of the lists has priority over the others. This can be implemented in the UI as multiple 'tabs' on an activity.

CRUD

Currently, there is some repetition in the 'description' of the activity model (e.g. how the activity creation form maps to the model), as it is currently done in both the form , the update action required for updating the activity and possibly some other places in the future. This repetition can be removed by creating an interface or something similar specifying creation, update and deletion of the activity in a method abstracting from the actual data-fields involved. The implementation of this 'interface' will specify the actual fields of the activity. I think that the usage of an appropriate Hydrator can help here, although it would probably have to be extended a bit, since the activity form doesn't directly map to the activity model.

Roadmap

1. Remove the old activity translation code and replace them with the translation mechanism described here. It is useful to start here, as there is a lot of old code that can simply be removed, which also would have a few dependencies on the other changes if left unchanged.

2. Create an interface for activity creation as described in the 'CRUD' section. This should remove most dependencies of the actual structure of the activity model, so it is best to do this before we actually change the model structure.

3. Split Activity into Activity and SignupList and add the activity categories.

4. Create the option for multiple signuplists.