39 calls using Pyro. It is important to note down that those two |
39 calls using Pyro. It is important to note down that those two |
40 sides, client/server, are disjointed and it is possible to execute |
40 sides, client/server, are disjointed and it is possible to execute |
41 a couple of calls in distincts processes to balance the load of |
41 a couple of calls in distincts processes to balance the load of |
42 your web site on one or more machines. |
42 your web site on one or more machines. |
43 |
43 |
|
44 .. _TermsVocabulary: |
44 |
45 |
45 Terms and vocabulary |
46 Terms and vocabulary |
46 -------------------- |
47 -------------------- |
47 |
48 |
48 *schema* |
49 *schema* |
49 the schema defines the data model of an application based on entities |
50 The schema defines the data model of an application based on entities |
50 and relations, thanks to the `yams`_ library. This is the core piece |
51 and relations, modeled with a comprehensive language made of Python |
|
52 classes based on `yams`_ library. This is the core piece |
51 of an application. It is initially defined in the file system and is |
53 of an application. It is initially defined in the file system and is |
52 stored in the database at the time an instance is created. `CubicWeb` |
54 stored in the database at the time an instance is created. `CubicWeb` |
53 provides a certain number of system entities included automatically as |
55 provides a certain number of system entities included automatically as |
54 it is necessarry for the core of `CubicWeb` and a library of |
56 it is necessarry for the core of `CubicWeb` and a library of |
55 cubes that can be explicitely included if necessarry. |
57 cubes that can be explicitely included if necessarry. |
56 |
58 |
57 |
59 |
58 *entity type* |
60 *entity type* |
59 an entity is a set of attributes; the essential attribute of |
61 An entity is a set of attributes; the essential attribute of |
60 an entity is its key, named eid |
62 an entity is its key, named eid |
61 |
63 |
62 *relation type* |
64 *relation type* |
63 entities are linked to each others by relations. In `CubicWeb` |
65 Entities are linked to each others by relations. In `CubicWeb` |
64 relations are binary: by convention we name the first item of |
66 relations are binary: by convention we name the first item of |
65 a relation the `subject` and the second the `object`. |
67 a relation the `subject` and the second the `object`. |
66 |
68 |
67 *final entity type* |
69 *final entity type* |
68 final types corresponds to the basic types such as string of characters, |
70 Final types corresponds to the basic types such as string of characters, |
69 integers... Those types have a main property which is that they can |
71 integers... Those types have a main property which is that they can |
70 only be used as `object` of a relation. The attributes of an entity |
72 only be used as `object` of a relation. The attributes of an entity |
71 (non final) are entities (finals). |
73 (non final) are entities (finals). |
72 |
74 |
73 *final relation type* |
75 *final relation type* |
74 a relation is said final if its `object` is a final type. This is equivalent |
76 A relation is said final if its `object` is a final type. This is equivalent |
75 to an entity attribute. |
77 to an entity attribute. |
76 |
78 |
77 *repository* |
79 *repository* |
78 this is the RQL server side of `CubicWeb`. Be carefull not to get |
80 This is the RQL server side of `CubicWeb`. Be carefull not to get |
79 confused with a Mercurial repository or a debian repository. |
81 confused with a Mercurial repository or a debian repository. |
80 |
82 |
81 *source* |
83 *source* |
82 a data source is a container of data (SGBD, LDAP directory...) integrated in the |
84 A data source is a container of data (SGBD, LDAP directory, `Google |
|
85 App Engine`'s datastore ...) integrated in the |
83 `CubicWeb` repository. This repository has at least one source, `system` which |
86 `CubicWeb` repository. This repository has at least one source, `system` which |
84 contains the schema of the application, plain-text index and others |
87 contains the schema of the application, plain-text index and others |
85 vital informations for the system. |
88 vital informations for the system. |
86 |
89 |
87 *configuration* |
90 *configuration* |
88 it is possible to create differents configurations for an instance: |
91 It is possible to create differents configurations for an instance: |
89 |
92 |
90 - ``repository`` : repository only, accessible for clients using Pyro |
93 - ``repository`` : repository only, accessible for clients using Pyro |
91 - ``twisted`` : web interface only, access the repository using Pyro |
94 - ``twisted`` : web interface only, access the repository using Pyro |
92 - ``all-in-one`` : web interface and repository in a single process. |
95 - ``all-in-one`` : web interface and repository in a single process. |
93 The repository could be or not accessible using Pyro. |
96 The repository could be or not accessible using Pyro. |
94 |
97 |
95 *cube* |
98 *cube* |
96 a cube is a model grouping one or multiple data types and/or views |
99 A cube is a model grouping one or multiple data types and/or views |
97 to provide a specific functionnality or a complete `CubicWeb` application |
100 to provide a specific functionnality or a complete `CubicWeb` application |
98 potentially using other cubes. The available subes are located in the file |
101 potentially using other cubes. The available subes are located in the file |
99 system at `/path/to/forest/cubicweb/cubes` |
102 system at `/path/to/forest/cubicweb/cubes`. |
|
103 Larger applications can be built faster by importing cubes, |
|
104 adding entities and relationships and overriding the |
|
105 views that need to display or edit informations not provided by |
|
106 cubes. |
100 |
107 |
101 *instance* |
108 *instance* |
102 an instance is a specific installation of a cube. All the required |
109 An instance is a specific installation of a cube. All the required |
103 configuration files necessarry for the well being of your web application |
110 configuration files necessarry for the well being of your web application |
104 are grouped in an instance. This will refer to the cube(s) your application |
111 are grouped in an instance. This will refer to the cube(s) your application |
105 is based on. |
112 is based on. |
106 By example logilab.org and our intranet are two instances of a single |
113 By example logilab.org and our intranet are two instances of a single |
107 cube jpl, developped internally. |
114 cube jpl, developped internally. |
108 The instances are defined in the directory `~/etc/cubicweb.d`. |
115 The instances are defined in the directory `~/etc/cubicweb.d`. |
109 |
116 |
110 *application* |
117 *application* |
111 the term application is sometime used to talk about an instance |
118 The term application is sometime used to talk about an instance |
112 and sometimes to talk of a cube depending on the context. |
119 and sometimes to talk of a cube depending on the context. |
113 So we would like to avoid using this term and try to use *cube* and |
120 So we would like to avoid using this term and try to use *cube* and |
114 *instance* instead. |
121 *instance* instead. |
115 |
122 |
116 *result set* |
123 *result set* |
117 this object contains the results of an RQL query and information on the query. |
124 This object contains the results of an RQL query sent to the source |
|
125 and information on the query. |
118 |
126 |
119 *Pyro* |
127 *Pyro* |
120 `Python Remote Object`_, distributed objects system similar to Java's RMI |
128 `Python Remote Object`_, distributed objects system similar to Java's RMI |
121 (Remote Method Invocation), which can be used for the dialog between the web |
129 (Remote Method Invocation), which can be used for the dialog between the web |
122 side of the framework and the RQL repository. |
130 side of the framework and the RQL repository. |
123 |
131 |
|
132 *query language* |
|
133 A full-blown query language named RQL is used to formulate requests |
|
134 to the database or any sources such as LDAP or `Google App Engine`'s |
|
135 datastore. |
|
136 |
|
137 *views* |
|
138 A view is applied to a `result set` to present it as HTML, XML, |
|
139 JSON, CSV, etc. Views are implemented as Python classes. There is no |
|
140 templating language. |
|
141 |
|
142 *generated user interface* |
|
143 A user interface is generated on-the-fly from the schema definition: |
|
144 entities can be created, displayed, updated and deleted. As display |
|
145 views are not very fancy, it is usually necessary to develop your |
|
146 own. Any generated view can be overridden by defining a new one with |
|
147 the same identifier. |
|
148 |
|
149 |
124 .. _`Python Remote Object`: http://pyro.sourceforge.net/ |
150 .. _`Python Remote Object`: http://pyro.sourceforge.net/ |
125 .. _`yams`: http://www.logilab.org/project/name/yams/ |
151 .. _`yams`: http://www.logilab.org/project/name/yams/ |
126 |
152 |
127 |
153 |
128 `CubicWeb` engine |
154 `CubicWeb` engine |