~johannes.baiter/mnemosyne-proj/mnemodroid

« back to all changes in this revision

Viewing changes to src/com/mnemodroid/mnemosyne/mnemosyne/libmnemosyne/card_type.py

  • Committer: Johannes Baiter
  • Date: 2011-02-15 00:30:59 UTC
  • Revision ID: johannes.baiter@gmail.com-20110215003059-83fn5ebmjs89jl2d
Relocated python scripts, added README and shellscript for tarball-creation, some bugfixes

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
#
2
 
# card_type.py <Peter.Bienstman@UGent.be>
3
 
#
4
 
 
5
 
from mnemosyne.libmnemosyne.card import Card
6
 
from mnemosyne.libmnemosyne.utils import CompareOnId
7
 
from mnemosyne.libmnemosyne.component import Component
8
 
 
9
 
 
10
 
class CardType(Component, CompareOnId):
11
 
 
12
 
    """A card type groups a number of fact views on a certain fact, thereby
13
 
    forming a set of related cards.
14
 
 
15
 
    A card type needs an id as well as a name, because the name can change
16
 
    for different translations. It is best to keep the id short, as it will
17
 
    show up in the card id as well.
18
 
 
19
 
    Inherited card types should have ids where :: separates the different
20
 
    levels of the hierarchy, e.g. parent_id::child_id.
21
 
    
22
 
    The keys from the fact are also given more verbose names here, as well
23
 
    as an optional language code, e.g. for text-to-speech processing.
24
 
    This is not done in fact.py, on one hand to save space in the database,
25
 
    and on the other hand to allow the possibility that different card types
26
 
    give different names to the same key. (E.g. foreign word' could be
27
 
    called 'French' in a French card type, or 'pronunciation' could be
28
 
    called 'reading' in a Kanji card type.) This in done in self.fields,
29
 
    which is a list of the form [(fact_key, fact_key_name, language_code)].
30
 
    It is tempting to use a dictionary here, but we can't do that since
31
 
    ordering is important.
32
 
 
33
 
    Fields which need to be different for all facts belonging to this card
34
 
    type are listed in unique_fields.
35
 
 
36
 
    Note that a fact could contain more data than those listed in the card
37
 
    type's 'fields' variable, which could be useful for card types needing
38
 
    hidden fields.
39
 
 
40
 
    We could use the component manager to track fact views, but this is
41
 
    probably overkill.
42
 
 
43
 
    The function 'fact_data' typically just returns a dictionary which is
44
 
    typically just fact.data, butwhich can also be generated on the fly,
45
 
    as e.g. in the cloze card type.
46
 
    
47
 
    The functions 'create_related_cards' and 'edit_related_cards' can be
48
 
    overridden by card types which can have a varying number of fact views,
49
 
    e.g. the cloze card type.
50
 
 
51
 
    """
52
 
    
53
 
    id = "-1"
54
 
    name = ""
55
 
    component_type = "card_type"
56
 
    _renderer = None
57
 
 
58
 
    fields = None
59
 
    fact_views = None
60
 
    unique_fields = None
61
 
    required_fields = None
62
 
    keyboard_shortcuts = {}
63
 
    extra_data = {}
64
 
 
65
 
    def keys(self):
66
 
        return set(fact_key for (fact_key, fact_key_name,
67
 
                   fact_key_language) in self.fields)
68
 
 
69
 
    def key_names(self):
70
 
        return [fact_key_name for (fact_key, fact_key_name,
71
 
               fact_key_language) in self.fields]
72
 
    
73
 
    def key_with_name(self, key_name):
74
 
        for fact_key, fact_key_name, fact_key_language in self.fields:
75
 
            if fact_key_name == key_name:
76
 
                return fact_key
77
 
 
78
 
    def is_data_valid(self, fact_data):
79
 
        for required in self.required_fields:
80
 
            if not fact_data[required]:
81
 
                return False
82
 
        return True
83
 
 
84
 
    # Note: we don't call render_chain in card.question because Card is not
85
 
    # a Component and has no access to the render chains.
86
 
 
87
 
    def render_question(self, card, render_chain="default", **render_args):
88
 
        return self.render_chain(render_chain).\
89
 
            render_question(card, **render_args)
90
 
       
91
 
    def render_answer(self, card, render_chain="default", **render_args):
92
 
        return self.render_chain(render_chain).\
93
 
            render_answer(card, **render_args)
94
 
 
95
 
    # The following functions can be overridden by speciality card types.
96
 
        
97
 
    def fact_data(self, card):
98
 
        return card.fact.data
99
 
 
100
 
    def create_related_cards(self, fact):
101
 
 
102
 
        """Initial grading of cards and storing in the database should not happen
103
 
        here, but is done in the main controller.
104
 
 
105
 
        """
106
 
        
107
 
        return [Card(self, fact, fact_view) for fact_view in self.fact_views]
108
 
 
109
 
    def edit_related_cards(self, fact, new_fact_data):
110
 
 
111
 
        """If for the card type this operation results in edited, added or
112
 
        deleted card data apart from the edited fact data from which they
113
 
        derive, these should be returned here, so that they can be taken into
114
 
        account in the database storage.
115
 
 
116
 
        Initial grading of cards and storing in the database should not happen
117
 
        here, but is done in the main controller.
118
 
 
119
 
        """
120
 
 
121
 
        new_cards, edited_cards, deleted_cards = [], [], []
122
 
        return new_cards, edited_cards, deleted_cards
123
 
    
124
 
    def before_repetition(self, card):
125
 
        pass
126
 
 
127
 
    def after_repetition(self, card):
128
 
        pass