A card type groups a number of fact views on a certain fact, thereby forming a set of sister cards.
A card type needs an id as well as a name, because the name can change for different translations.
Inherited card types should have ids where :: separates the different levels of the hierarchy, e.g. parent_id::child_id.
The keys from the fact are also given more verbose names here. This is not done in fact.py, on one hand to save space in the database, and on the other hand to allow the possibility that different card types give different names to the same key. (E.g. foreign word’ could be called ‘French’ in a French card type, or ‘pronunciation’ could be called ‘reading’ in a Kanji card type.) This is done in self.fields, which is a list of the form [(fact_key, fact_key_name)]. It is tempting to use a dictionary here, but we can’t do that since ordering is important.
Fields which need to be different for all facts belonging to this card type are listed in ‘unique_fields’.
Note that a fact could contain more data than those listed in the card type’s ‘fields’ variable, which could be useful for card types needing hidden fields, dynamically generated fields, ... .
We could use the component manager to track fact views, but this is probably overkill.
The functions ‘create_sister_cards’ and ‘edit_sister_cards’ can be overridden by card types which can have a varying number of fact views, e.g. the cloze card type.
Initial grading of cards and storing in the database should not happen here, but is done in the main controller.
If for the card type this operation results in edited, added or deleted card data apart from the edited fact data from which they derive, these should be returned here, so that they can be taken into account in the database storage.
Initial grading of cards and storing in the database should not happen here, but is done in the main controller.
Returns the data in fact of a card. Normally. this is just ‘card.fact.data’, but specialty card types (e.g. the cloze card type) can override this.
Check if all the required fields are present.
Sometimes, a card type can dynamically create a field when generating a question or an answer (see e.g. the cloze card type). Since the user cannot specify how this key should be formatted, it should be formatted like an other, static key. This function returns a dictionary with this correspondence.