|
1 Paramétrages et extensions spécifiques |
|
2 -------------------------------------- |
|
3 |
|
4 Valeurs par défaut dynamiques |
|
5 ````````````````````````````` |
|
6 Il est possible de définir dans le schéma des valeurs par défaut *statiques*. |
|
7 Il est également possible de définir des valeurs par défaut *dynamiques* en |
|
8 définissant sur la classe d'entité une méthode `default_<nom attribut>` pour |
|
9 un attribut donnée. |
|
10 |
|
11 |
|
12 Contrôle des attributs chargés et du tri par défaut |
|
13 ``````````````````````````````````````````````````` |
|
14 * l'attribut de classe `fetch_attrs` permet de définir sur une classe d'entité |
|
15 la liste des noms des attributs ou relations devant être chargés |
|
16 automatiquement lors de la récupération d'entité(s) de ce type. Dans le cas |
|
17 des relations, on est limité aux relations *sujets de cardinalité `?` ou `1`*. |
|
18 |
|
19 * la méthode de classe `fetch_order(attr, var)` prend en argument un nom |
|
20 d'attribut (ou de relation) et un nom de variable et doit retourner une chaine |
|
21 à utiliser dans la close "ORDERBY" d'une requête RQL pour trier |
|
22 automatiquement les listes d'entités de ce type selon cet attribut, ou `None` |
|
23 si l'on ne veut pas de tri sur l'attribut passé en argument. Par défaut les |
|
24 entités sont triées selon leur date de création |
|
25 |
|
26 * la méthode de classe `fetch_unrelated_order(attr, var)` est similaire à la |
|
27 méthode `fetch_order` mais est utilisée essentiellement pour contrôler le tri |
|
28 des listes déroulantes permettant de créer des relations dans la vue d'édition |
|
29 d'une entité |
|
30 |
|
31 La fonction `fetch_config(fetchattrs, mainattr=None)` permet de simplifier la |
|
32 définition des attributs à précharger et du tri en retournant une liste des |
|
33 attributs à précharger (en considérant ceux de la classe `AnyEntity` |
|
34 automatiquement) et une fonction de tri sur l'attribut "principal" (le 2eme |
|
35 argument si spécifié ou sinon le premier attribut de la liste `fetchattrs`). |
|
36 Cette fonction est définie dans le package `cubicweb.entities`. |
|
37 |
|
38 Par exemple : :: |
|
39 |
|
40 class Transition(AnyEntity): |
|
41 """...""" |
|
42 id = 'Transition' |
|
43 fetch_attrs, fetch_order = fetch_config(['name']) |
|
44 |
|
45 Indique que pour le type d'entité "Transition" il faut précharger l'attribut |
|
46 "name" et trier par défaut selon cet attribut. |
|
47 |
|
48 |
|
49 Contrôle des formulaires d'édition |
|
50 `````````````````````````````````` |
|
51 Il est possible de contrôler les attributs/relations dans la vue d'édition |
|
52 simple ou multiple à l'aide des *rtags* suivants : |
|
53 |
|
54 * `primary`, indique qu'un attribut ou une relation doit être incorporé dans |
|
55 les formulaires d'édition simple et multiple. Dans le cas d'une relation, |
|
56 le formulaire d'édition de l'entité liée sera inclus dans le formulaire |
|
57 |
|
58 * `secondary`, indique qu'un attribut ou une relation doit être incorporé dans |
|
59 le formulaire d'édition simple uniquement. Dans le cas d'une relation, |
|
60 le formulaire d'édition de l'entité liée sera inclus dans le formulaire |
|
61 |
|
62 * `generic`, indique qu'une relation doit être incorporé dans le formulaire |
|
63 d'édition simple dans la boite générique d'ajout de relation |
|
64 |
|
65 * `generated`, indique qu'un attribut est caculé dynamiquement ou autre, et |
|
66 qu'il ne doit donc pas être présent dans les formulaires d'édition |
|
67 |
|
68 Au besoin il est possible de surcharger la méthode |
|
69 `relation_category(rtype, x='subject')` pour calculer dynamiquement la catégorie |
|
70 d'édition d'une relation. |
|
71 |
|
72 |
|
73 Contrôle de la boîte "add_related" |
|
74 `````````````````````````````````` |
|
75 La boite `add related` est une boite automatique proposant de créer une entité |
|
76 qui sera automatiquement liée à l'entité de départ (le contexte dans lequel |
|
77 s'affiche la boite). Par défaut, les liens présents dans cette boite sont |
|
78 calculés en fonction des propriétés du schéma de l'entité visualisée, mais il |
|
79 est possible de les spécifier explicitement à l'aide des *rtags* suivants : |
|
80 |
|
81 * `link`, indique qu'une relation est généralement créée vers une entité |
|
82 existante et qu'il ne faut donc pas faire apparaitre de lien pour cette |
|
83 relation |
|
84 |
|
85 * `create`, indique qu'une relation est généralement créée vers de nouvelles |
|
86 entités et qu'il faut donc faire apparaitre un lien pour créer une nouvelle |
|
87 entité et la lier automatiquement |
|
88 |
|
89 Au besoin il est possible de surcharger la méthode |
|
90 `relation_mode(rtype, targettype, x='subject')` pour caculer dynamiquement la |
|
91 catégorie de création d'une relation. |
|
92 |
|
93 A noter également que si au moins une action dans la catégorie "addrelated" est |
|
94 trouvée pour le contexte courant, le fonctionnement automatique est désactivé |
|
95 en faveur du fonctionnement explicite (i.e. affichage des actions de la |
|
96 catégorie "addrelated" uniquement). |
|
97 |
|
98 Contrôle des formulaires de filtrage de table |
|
99 ````````````````````````````````````````````` |
|
100 La vue "table" par défaut gère dynamiquement un formulaire de filtrage du |
|
101 contenu de celle-ci. L'algorithme est le suivant : |
|
102 |
|
103 1. on considère que la première colonne contient les entités à restreindre |
|
104 2. on recupère la première entité de la table (ligne 0) pour "représenter" |
|
105 toutes les autres |
|
106 3. pour toutes les autres variables définies dans la requête originale : |
|
107 |
|
108 1. si la variable est liée à la variable principale par au moins une |
|
109 n'importe quelle relation |
|
110 2. on appelle la méthode `filterform_vocabulary(rtype, x)` sur l'entité |
|
111 et si rien est retourné (ou plus exactement un tuple de valeur `None`, |
|
112 voir ci-dessous) on passe à la variable suivante, sinon un élément de |
|
113 formulaire de filtrage sera créé avec les valeurs de vocabulaire |
|
114 retournées |
|
115 |
|
116 4. il n'y a pas d'autres limitations sur le rql, il peut comporter des clauses |
|
117 de tris, de groupes... Des fonctions javascripts sont utilisées pour |
|
118 regénérer une requête à partir de la requête de départ et des valeurs |
|
119 séléctionnées dans les filtres de formulaire. |
|
120 |
|
121 |
|
122 La méthode `filterform_vocabulary(rtype, x, var, rqlst, args, cachekey)` prend |
|
123 en argument le nom d'une relation et la "cible", qui indique si l'entité sur |
|
124 laquelle la méthode est appellée est sujet ou objet de la relation. Elle doit |
|
125 retourner : |
|
126 |
|
127 * un 2-uple de None si elle ne sait pas gérer cette relation |
|
128 |
|
129 * un type et une liste contenant le vocabulaire |
|
130 |
|
131 * la liste doit contenir des couples (valeur, label) |
|
132 * le type indique si la valeur désigne un nombre entier (`type == 'int'`), une |
|
133 chaîne de caractères (`type == 'string'`) ou une entité non finale (`type |
|
134 == 'eid'`) |
|
135 |
|
136 Par exemple dans notre application de gestion de tickets, on veut pouvoir |
|
137 filtrés ceux-ci par : |
|
138 |
|
139 * type |
|
140 * priorité |
|
141 * état (in_state) |
|
142 * étiquette (tags) |
|
143 * version (done_in) |
|
144 |
|
145 On définit donc la méthode suivante : :: |
|
146 |
|
147 |
|
148 class Ticket(AnyEntity): |
|
149 |
|
150 ... |
|
151 |
|
152 def filterform_vocabulary(self, rtype, x, var, rqlst, args, cachekey): |
|
153 _ = self.req._ |
|
154 if rtype == 'type': |
|
155 return 'string', [(x, _(x)) for x in ('bug', 'story')] |
|
156 if rtype == 'priority': |
|
157 return 'string', [(x, _(x)) for x in ('minor', 'normal', 'important')] |
|
158 if rtype == 'done_in': |
|
159 rql = insert_attr_select_relation(rqlst, var, rtype, 'num') |
|
160 return 'eid', self.req.execute(rql, args, cachekey) |
|
161 return super(Ticket, self).filterform_vocabulary(rtype, x, var, rqlst, |
|
162 args, cachekey) |
|
163 |
|
164 |
|
165 NOTE: Le support du filtrage sur les étiquettes et l'état est installé |
|
166 automatiquement, pas besoin de le gérer ici. |