|
1 .. -*- coding: utf-8 -*- |
|
2 |
|
3 Fondements `CubicWeb` |
|
4 ===================== |
|
5 |
|
6 Architecture globale |
|
7 -------------------- |
|
8 .. image:: archi_globale.png |
|
9 |
|
10 **Note**: en pratique la partie cliente et la partie serveur sont |
|
11 généralement intégrées dans le même processus et communiquent donc |
|
12 directement, sans nécessiter des appels distants via Pyro. Il est |
|
13 cependant important de retenir que ces deux parties sont disjointes |
|
14 et qu'il est même possible d'en exécuter plusieurs exemplaires dans |
|
15 des processus distincts pour répartir la charge globale d'un site |
|
16 sur une ou plusieurs machines. |
|
17 |
|
18 Concepts et vocabulaire |
|
19 ----------------------- |
|
20 |
|
21 *schéma* |
|
22 le schéma définit le modèle de données d'une application sous forme |
|
23 d'entités et de relations, grâce à la biblithèque `yams`_. C'est |
|
24 l'élément central d'une application. Il est initialement défini sur |
|
25 le système de fichiers et est stocké dans la base de données lors de |
|
26 la création d'une instance. `CubicWeb` fournit un certain nombres de |
|
27 types d'entités inclus systématiquement car nécessaire au noyau |
|
28 `CubicWeb` et une librairie de composants devant être inclus |
|
29 explicitement le cas échéant. |
|
30 |
|
31 *type d'entité* |
|
32 une entité est un ensemble d'attributs ; l'attribut de |
|
33 base de toute entité, qui est sa clef, est l'eid |
|
34 |
|
35 *type de relation* |
|
36 les entités sont liées entre elles par des relations. Dans cubicweb les |
|
37 relations sont binaires : par convention on nomme le premier terme |
|
38 d'une relation son 'sujet' et le second son 'objet'. |
|
39 |
|
40 *type d'entité final* |
|
41 les types finaux correspondent aux types de bases comme les chaînes |
|
42 de caractères, les nombres entiers... Une propriété de ces types est |
|
43 qu'ils ne peuvent être utilisés qu'uniquement comme objet d'une |
|
44 relation. Les attributs d'une entité (non finale) sont des entités |
|
45 (finales). |
|
46 |
|
47 *type de relation finale* |
|
48 une relation est dite finale si son objet est un type final. Cela revient à |
|
49 un attribut d'une entité. |
|
50 |
|
51 *entrepôt* |
|
52 ou *repository*, c'est la partie serveur RQL de `CubicWeb`. Attention à ne pas |
|
53 confondre avec un entrepôt mercurial ou encore un entrepôt debian. |
|
54 |
|
55 *source* |
|
56 une source de données est un conteneur de données quelquonque (SGBD, annuaire |
|
57 LDAP...) intégré par l'entrepôt `CubicWeb`. Un entrepôt possède au moins une source |
|
58 dite "system" contenant le schéma de l'application, l'index plein-texte et |
|
59 d'autres informations vitales au système. |
|
60 |
|
61 *configuration* |
|
62 il est possible de créer différentes configurations pour une instance : |
|
63 |
|
64 - ``repository`` : entrepôt uniquement, accessible pour les clients via Pyro |
|
65 - ``twisted`` : interface web uniquement, communiquant avec un entrepôt via Pyro |
|
66 - ``all-in-one`` : interface web et entrepôt dans un seul processus. L'entrepôt |
|
67 peut ou non être accessible via Pyro |
|
68 |
|
69 *composant* |
|
70 un composant est un modèle regroupant un ou plusieurs types de données et/ou |
|
71 des vues afin de fournir une fonctionalité précise, ou une application `CubicWeb` |
|
72 complète utilisant éventuellement d'autres composants. Les différents |
|
73 composants disponibles sur une machine sont installés dans |
|
74 `/usr/share/cubicweb/cubes` |
|
75 |
|
76 *instance* |
|
77 une instance est une installation spécifique d'un template. Par exemple |
|
78 intranet/jpl et logilab.org sont deux instances du composant jpl. Les |
|
79 instances sont définies dans le répertoire `/etc/cubicweb.d`. |
|
80 |
|
81 *application* |
|
82 le mot application est utilisé parfois pour parler d'une instance et parfois |
|
83 d'un composant, en fonction du contexte... Mieux vaut donc éviter de |
|
84 l'utiliser et utiliser plutôt *composant* et *instance*. |
|
85 |
|
86 *result set* |
|
87 objet encaspulant les résultats d'une requête RQL et des informations sur |
|
88 cette requête. |
|
89 |
|
90 *Pyro* |
|
91 `Python Remote Object`_, système d'objets distribués pur Python similaire à |
|
92 Java's RMI (Remote Method Invocation), pouvant être utilisé pour la |
|
93 communication entre la partie web du framework et l'entrepôt RQL. |
|
94 |
|
95 .. _`Python Remote Object`: http://pyro.sourceforge.net/ |
|
96 .. _`yams`: http://www.logilab.org/project/name/yams/ |
|
97 |
|
98 |
|
99 Structure standard d'un composant |
|
100 --------------------------------- |
|
101 |
|
102 Un composant complexe est structuré selon le modèle suivant : |
|
103 |
|
104 :: |
|
105 |
|
106 moncomposant/ |
|
107 | |
|
108 |-- schema.py |
|
109 | |
|
110 |-- entities/ |
|
111 | |
|
112 |-- sobjects/ |
|
113 | |
|
114 |-- views/ |
|
115 | |
|
116 |-- test/ |
|
117 | |
|
118 |-- i18n/ |
|
119 | |
|
120 |-- data/ |
|
121 | |
|
122 |-- migration/ |
|
123 | |- postcreate.py |
|
124 | \- depends.map |
|
125 | |
|
126 |-- debian/ |
|
127 | |
|
128 \-- __pkginfo__.py |
|
129 |
|
130 On peut utiliser de simple module python plutôt que des répertoires (packages), |
|
131 par ex.: |
|
132 |
|
133 :: |
|
134 |
|
135 moncomposant/ |
|
136 | |
|
137 |-- entities.py |
|
138 |-- hooks.py |
|
139 \-- views.py |
|
140 |
|
141 |
|
142 où : |
|
143 |
|
144 * ``schema`` contient la définition du schéma (coté serveur uniquement) |
|
145 * ``entities`` contient les définitions d'entités (coté serveur et interface web) |
|
146 * ``sobjects`` contient les crochets et/ou vues de notification (coté serveur |
|
147 uniquement) |
|
148 * ``views`` contient les différents composants de l'interface web (coté interface |
|
149 web uniquement) |
|
150 * ``test`` contient les tests spécifiques à l'application (non installé) |
|
151 * ``i18n`` contient les catalogues de messages pour les langues supportées (coté |
|
152 serveur et interface web) |
|
153 * ``data`` contient des fichiers de données arbitraires servis statiquement |
|
154 (images, css, fichiers javascripts)... (coté interface web uniquement) |
|
155 * ``migration`` contient le fichier d'initialisation de nouvelles instances |
|
156 (``postcreate.py``) et générallement un fichier donnant les dépendances `CubicWeb` du |
|
157 composant en fonction de la version de celui-ci (``depends.map``) |
|
158 * ``debian`` contient les fichiers contrôlant le packaging debian (vous y |
|
159 trouverez les fichiers classiques ``control``, ``rules``, ``changelog``... (non |
|
160 installé) |
|
161 * le fichier ``__pkginfo__.py`` donne un certain nombre de méta-données sur le |
|
162 composant, notamment le nom de la distribution et la version courante (coté |
|
163 serveur et interface web) ou encore les sous-composants utilisés par ce |
|
164 composant. |
|
165 |
|
166 Le strict minimum étant : |
|
167 |
|
168 * le fichier ``__pkginfo__.py`` |
|
169 * la définition du schéma |