L'=E9quipe de d=E9veloppement de CubicWeb a le plaisir de vous annoncer la
publication de la version 3.0.0, surnomm=E9e ShowTime.
Qu'est-ce que CubicWeb?
-----------------------
Avec CubicWeb, le Web S=E9mantique devient un jeu de construction !
CubicWeb_ est une plate-forme de d=E9veloppement d'application web
s=E9mantique,
disponible sous license LGPL, qui permet aux d=E9veloppeurs de
construire
efficacement des applications web en assemblant des composants
(appel=E9s cubes)
et en suivant les principes bien connus de la programmation orient=E9e-
objet.
Ses principales caract=E9ristiques sont:
* un moteur qui utilise une repr=E9sentation explicite du mod=E8le de
donn=E9es de
l'application,
* un langage de requ=EAte nomm=E9 RQL qui est semblable au SPARQL du
W3C,
* un m=E9canisme de s=E9lection+vue qui permet la g=E9n=E9ration semi-
automatique de XHTML/XML/JSON/text,
* une biblioth=E8que de composants r=E9utilisables (mod=E8le de donn=E9=
e
et vues)
qui satisfait les besoins les plus courants,
* la puissance et l'adaptabilit=E9 du langage de programmation
Python,
* la solidit=E9 des bases SQL, des annuaires LDAP, de Subversion et
Mercurial
pour le stockage des donn=E9es.
D=E9velopp=E9 depuis 2000 par un projet de R&D qui se poursuit encore
aujourd'hui,
servant plusieurs centaines de milliers de visiteurs par jour pour
certains
sites, CubicWeb est une solution compl=E8te et =E9prouv=E9e pour d=E9velopp=
er
des
applications web, qui promeut la qualit=E9, la r=E9utilisabilit=E9 et
l'efficacit=E9.
L'incr=E9dule lira la pr=E9sentation_ de CubicWeb.
Le d=E9veloppeur se joindra au projet =E0 la forge_.
L'impatient sautera sur les consignes d'installation_.
L'équipe de développement de CubicWeb a le plaisir de vous annoncer la publication de la version 3.0.0, surnommée ShowTime.
En survolant rapidement la présentation, ça m'a rappelé Django (que je n'ai également que survolé)... Y a un rapport ou pas ?
-- William Dodé - http://flibuste.net Informaticien Indépendant
nchauvat (Logilab)
Bonjour William,
On 31 déc 2008, 14:12, William Dode wrote:
En survolant rapidement la présentation, ça m'a rappelé Django (que je n'ai également que survolé)... Y a un rapport ou pas ?
Tout d'abord, on peut souligner qu'il n'y a aucun code en commun, bien que les deux soient écrits en Python.
Administration ---------------------
Il y a des commandes manage.py et django-admin.py pour faire l'administration de Django et il y a une commande cubicweb-ctl qui permet de faire l'administration de CubicWeb. A ma connaissance, il n'y a pas de commande équivalente à 'cubicweb-ctl db-copy' qui permet de faire une copie d'une application en production pour tester des changements avant sa migration et il n'y a pas d'équivalent des scripts de migration qui permettent de passer sans effort d'une version de la plateforme ou d'une version d'un composant à l'autre.
Stockage des données ---------------------------------
Django utilise une base SQL pour le stockage et cubicweb a besoin d'au moins une base SQL (sqlite, postgresql, mysql) pour fonctionner, mais peut aussi utiliser des données qui sont dans un annuaire LDAP et dans un entrepôt subversion ou mercurial (voir plus bas interrogation des données).
Modèle de données ----------------------------
Django et CubicWeb permettent de décrire le modèle de données en Python, mais la description de Django est du niveau de la base SQL alors que celle de CubicWeb est plus abstraite, ce qui est plus flexible d'une manière générale et permet à CubicWeb d'utiliser des données qui viennent de plusieurs sources de natures différentes. En particulier, avec Django une relation entre objets doit être définie comme une clef (comme dans class Choice(models.Model): poll = models.ForeignKey(Poll)) alors que dans CubicWeb, une relation est une relation nommée (comme dans class Poll: has_choice = ObjectRelation ('Choice', cardinality='1+')). D'autre part Django mélange description du modèle de données et classe de base des objets renvoyés par l'ORM alors que CubicWeb distingue les deux, ce qui évite nombre de problèmes.
Interrogation des données -------------------------------------
Django utilise un ORM avec une syntaxe séduisante au premier abord (par exemple: latest_poll_list = Poll.objects.all().order_by('- pub_date')[:5]), mais qui devient rapidement inextricable ou complètement inefficace pour une véritable application qui demande des requêtes non triviales. CubicWeb dispose de son propre langage d'interrogation, RQL, qui reprend à l'identique les noms utilisés dans la définition du modèle de données et qui permet de s'abstraire des sources interrogées. L'exemple précédent de Django s'écrit en RQL " Any P ORDERBY D LIMIT 5 WHERE P is Poll, P pub_date D". Si les utilisateurs sont stockés dans un annuaire LDAP, des textes dans un entrepôt subversion et des états dans une table de la base SQL, CubicWeb permet de faire la requête "Any U,T,S WHERE U is EUser, T is VersionedFile, S is State, U author T, T in_state S" qui renvoie une liste de triplets (donc un tableau à trois colonnes), lequels peuvent être convertis en objets Python avec la méthode entities() si l'approche objet est préférable à l'approche tableau de données.
Interface web --------------------
Django et CubicWeb peuvent générer une partie de l'interface web, mais CubicWeb dispose du concept de vue, qui est quasi-inexistant dans le monde des frameworks web. Ce concept de vue est à rapprocher du concept de protocol (ou interface) en programmation orientée objet. Une vue peut être appliquée à tout ensemble de données dont les éléments respectent le bon protocol (la bonne interface). Ainsi la vue 'oneline' peut être appliquée à n'importe quelle collection d'objets puisque tous les objets renvoyés par une requête héritent de Entity qui définit 'oneline'. Pour prendre un autre exemple, la vue 'ical' peut être appliquée à toute sélection d'objet (même si la sélec tion est hétérogène et comprend des rendez-vous et des versions) pour peu que chaque objet de cette sélection implémente l'interface Calendar (avec les rendez-vous qui donnent la date du rendez-vous et les versions qui donnent la date de sortie prévue).
Programmation par composant ---------------------------------------------
Django permet de réutiliser du code existant, mais l'assemblage des morceaux est laborieux. Dans CubicWeb, grâce au niveau d'abstraction de la description du modèle de données, au langage d'interrogation RQL et au concept de vue appliquée à des sélections d'entités, il est possible de définir des composants en associant un modèle de données réduit et des vues. Assembler des composants se limite alors à rajouter des relations entre les modèles de données de ces composants et à redéfinir les vues qui doivent afficher ces données. Si je veux assembler le composant Poll et le composant Comment, il me suffit de faire "from cubes.poll import Poll ; from cubes.comment import Comment ; class MyComment(Comment): comments = SubjectRelation ('Poll')" et de redéfinir la vue principale de Poll pour y afficher le résultat de l'appel à execute("Any C WHERE C comments P, P eid %(x)s", {'x': poll_identifier})
J'espère avoir répondu à la question et suis bien évidemment dispos é à poursuivre la discussion sur ce sujet, mais peut-être sur la liste pour ne pas encombrer fr.comp.lang.python.
Cordialement,
Bonjour William,
On 31 déc 2008, 14:12, William Dode <w...@flibuste.net> wrote:
En survolant rapidement la présentation, ça m'a rappelé Django (que je
n'ai également que survolé)... Y a un rapport ou pas ?
Tout d'abord, on peut souligner qu'il n'y a aucun code en commun, bien
que les deux soient écrits en Python.
Administration
---------------------
Il y a des commandes manage.py et django-admin.py pour faire
l'administration de Django et il y a une commande cubicweb-ctl qui
permet de faire l'administration de CubicWeb. A ma connaissance, il
n'y a pas de commande équivalente à 'cubicweb-ctl db-copy' qui permet
de faire une copie d'une application en production pour tester des
changements avant sa migration et il n'y a pas d'équivalent des
scripts de migration qui permettent de passer sans effort d'une
version de la plateforme ou d'une version d'un composant à l'autre.
Stockage des données
---------------------------------
Django utilise une base SQL pour le stockage et cubicweb a besoin d'au
moins une base SQL (sqlite, postgresql, mysql) pour fonctionner, mais
peut aussi utiliser des données qui sont dans un annuaire LDAP et dans
un entrepôt subversion ou mercurial (voir plus bas interrogation des
données).
Modèle de données
----------------------------
Django et CubicWeb permettent de décrire le modèle de données en
Python, mais la description de Django est du niveau de la base SQL
alors que celle de CubicWeb est plus abstraite, ce qui est plus
flexible d'une manière générale et permet à CubicWeb d'utiliser des
données qui viennent de plusieurs sources de natures différentes. En
particulier, avec Django une relation entre objets doit être définie
comme une clef (comme dans class Choice(models.Model): poll =
models.ForeignKey(Poll)) alors que dans CubicWeb, une relation est une
relation nommée (comme dans class Poll: has_choice = ObjectRelation
('Choice', cardinality='1+')). D'autre part Django mélange description
du modèle de données et classe de base des objets renvoyés par l'ORM
alors que CubicWeb distingue les deux, ce qui évite nombre de
problèmes.
Interrogation des données
-------------------------------------
Django utilise un ORM avec une syntaxe séduisante au premier abord
(par exemple: latest_poll_list = Poll.objects.all().order_by('-
pub_date')[:5]), mais qui devient rapidement inextricable ou
complètement inefficace pour une véritable application qui demande des
requêtes non triviales. CubicWeb dispose de son propre langage
d'interrogation, RQL, qui reprend à l'identique les noms utilisés dans
la définition du modèle de données et qui permet de s'abstraire des
sources interrogées. L'exemple précédent de Django s'écrit en RQL " Any
P ORDERBY D LIMIT 5 WHERE P is Poll, P pub_date D". Si les
utilisateurs sont stockés dans un annuaire LDAP, des textes dans un
entrepôt subversion et des états dans une table de la base SQL,
CubicWeb permet de faire la requête "Any U,T,S WHERE U is EUser, T is
VersionedFile, S is State, U author T, T in_state S" qui renvoie une
liste de triplets (donc un tableau à trois colonnes), lequels peuvent
être convertis en objets Python avec la méthode entities() si
l'approche objet est préférable à l'approche tableau de données.
Interface web
--------------------
Django et CubicWeb peuvent générer une partie de l'interface web, mais
CubicWeb dispose du concept de vue, qui est quasi-inexistant dans le
monde des frameworks web. Ce concept de vue est à rapprocher du
concept de protocol (ou interface) en programmation orientée objet.
Une vue peut être appliquée à tout ensemble de données dont les
éléments respectent le bon protocol (la bonne interface). Ainsi la vue
'oneline' peut être appliquée à n'importe quelle collection d'objets
puisque tous les objets renvoyés par une requête héritent de Entity
qui définit 'oneline'. Pour prendre un autre exemple, la vue 'ical'
peut être appliquée à toute sélection d'objet (même si la sélec tion
est hétérogène et comprend des rendez-vous et des versions) pour peu
que chaque objet de cette sélection implémente l'interface Calendar
(avec les rendez-vous qui donnent la date du rendez-vous et les
versions qui donnent la date de sortie prévue).
Programmation par composant
---------------------------------------------
Django permet de réutiliser du code existant, mais l'assemblage des
morceaux est laborieux. Dans CubicWeb, grâce au niveau d'abstraction
de la description du modèle de données, au langage d'interrogation RQL
et au concept de vue appliquée à des sélections d'entités, il est
possible de définir des composants en associant un modèle de données
réduit et des vues. Assembler des composants se limite alors à
rajouter des relations entre les modèles de données de ces composants
et à redéfinir les vues qui doivent afficher ces données. Si je veux
assembler le composant Poll et le composant Comment, il me suffit de
faire "from cubes.poll import Poll ; from cubes.comment import
Comment ; class MyComment(Comment): comments = SubjectRelation
('Poll')" et de redéfinir la vue principale de Poll pour y afficher le
résultat de l'appel à execute("Any C WHERE C comments P, P eid %(x)s",
{'x': poll_identifier})
J'espère avoir répondu à la question et suis bien évidemment dispos é à
poursuivre la discussion sur ce sujet, mais peut-être sur la liste
cubicweb@lists.cubicweb.org pour ne pas encombrer fr.comp.lang.python.
En survolant rapidement la présentation, ça m'a rappelé Django (que je n'ai également que survolé)... Y a un rapport ou pas ?
Tout d'abord, on peut souligner qu'il n'y a aucun code en commun, bien que les deux soient écrits en Python.
Administration ---------------------
Il y a des commandes manage.py et django-admin.py pour faire l'administration de Django et il y a une commande cubicweb-ctl qui permet de faire l'administration de CubicWeb. A ma connaissance, il n'y a pas de commande équivalente à 'cubicweb-ctl db-copy' qui permet de faire une copie d'une application en production pour tester des changements avant sa migration et il n'y a pas d'équivalent des scripts de migration qui permettent de passer sans effort d'une version de la plateforme ou d'une version d'un composant à l'autre.
Stockage des données ---------------------------------
Django utilise une base SQL pour le stockage et cubicweb a besoin d'au moins une base SQL (sqlite, postgresql, mysql) pour fonctionner, mais peut aussi utiliser des données qui sont dans un annuaire LDAP et dans un entrepôt subversion ou mercurial (voir plus bas interrogation des données).
Modèle de données ----------------------------
Django et CubicWeb permettent de décrire le modèle de données en Python, mais la description de Django est du niveau de la base SQL alors que celle de CubicWeb est plus abstraite, ce qui est plus flexible d'une manière générale et permet à CubicWeb d'utiliser des données qui viennent de plusieurs sources de natures différentes. En particulier, avec Django une relation entre objets doit être définie comme une clef (comme dans class Choice(models.Model): poll = models.ForeignKey(Poll)) alors que dans CubicWeb, une relation est une relation nommée (comme dans class Poll: has_choice = ObjectRelation ('Choice', cardinality='1+')). D'autre part Django mélange description du modèle de données et classe de base des objets renvoyés par l'ORM alors que CubicWeb distingue les deux, ce qui évite nombre de problèmes.
Interrogation des données -------------------------------------
Django utilise un ORM avec une syntaxe séduisante au premier abord (par exemple: latest_poll_list = Poll.objects.all().order_by('- pub_date')[:5]), mais qui devient rapidement inextricable ou complètement inefficace pour une véritable application qui demande des requêtes non triviales. CubicWeb dispose de son propre langage d'interrogation, RQL, qui reprend à l'identique les noms utilisés dans la définition du modèle de données et qui permet de s'abstraire des sources interrogées. L'exemple précédent de Django s'écrit en RQL " Any P ORDERBY D LIMIT 5 WHERE P is Poll, P pub_date D". Si les utilisateurs sont stockés dans un annuaire LDAP, des textes dans un entrepôt subversion et des états dans une table de la base SQL, CubicWeb permet de faire la requête "Any U,T,S WHERE U is EUser, T is VersionedFile, S is State, U author T, T in_state S" qui renvoie une liste de triplets (donc un tableau à trois colonnes), lequels peuvent être convertis en objets Python avec la méthode entities() si l'approche objet est préférable à l'approche tableau de données.
Interface web --------------------
Django et CubicWeb peuvent générer une partie de l'interface web, mais CubicWeb dispose du concept de vue, qui est quasi-inexistant dans le monde des frameworks web. Ce concept de vue est à rapprocher du concept de protocol (ou interface) en programmation orientée objet. Une vue peut être appliquée à tout ensemble de données dont les éléments respectent le bon protocol (la bonne interface). Ainsi la vue 'oneline' peut être appliquée à n'importe quelle collection d'objets puisque tous les objets renvoyés par une requête héritent de Entity qui définit 'oneline'. Pour prendre un autre exemple, la vue 'ical' peut être appliquée à toute sélection d'objet (même si la sélec tion est hétérogène et comprend des rendez-vous et des versions) pour peu que chaque objet de cette sélection implémente l'interface Calendar (avec les rendez-vous qui donnent la date du rendez-vous et les versions qui donnent la date de sortie prévue).
Programmation par composant ---------------------------------------------
Django permet de réutiliser du code existant, mais l'assemblage des morceaux est laborieux. Dans CubicWeb, grâce au niveau d'abstraction de la description du modèle de données, au langage d'interrogation RQL et au concept de vue appliquée à des sélections d'entités, il est possible de définir des composants en associant un modèle de données réduit et des vues. Assembler des composants se limite alors à rajouter des relations entre les modèles de données de ces composants et à redéfinir les vues qui doivent afficher ces données. Si je veux assembler le composant Poll et le composant Comment, il me suffit de faire "from cubes.poll import Poll ; from cubes.comment import Comment ; class MyComment(Comment): comments = SubjectRelation ('Poll')" et de redéfinir la vue principale de Poll pour y afficher le résultat de l'appel à execute("Any C WHERE C comments P, P eid %(x)s", {'x': poll_identifier})
J'espère avoir répondu à la question et suis bien évidemment dispos é à poursuivre la discussion sur ce sujet, mais peut-être sur la liste pour ne pas encombrer fr.comp.lang.python.
Cordialement,
Adrien Di Mascio
Bonjour,
Je voudrais juste rajouter brièvement quelques compléments d'information à ce qu'a dit Nicolas dans son précédent message.
Stockage des données ---------------------------------
Django utilise une base SQL pour le stockage et cubicweb a besoin d'au moins une base SQL (sqlite, postgresql, mysql) pour fonctionner, mais peut aussi utiliser des données qui sont dans un annuaire LDAP et dans un entrepôt subversion ou mercurial (voir plus bas interrogation des données).
Une application CubicWeb est également capable d'interroger une autre application CubicWeb pour peu que les deux applications aient une partie de leur définition de schéma en commun. Il suffit alors de rajouter la seconde application comme étant une source de données possible et les requêtes iront interroger cette seconde application de manière transparente.
Interrogation des données -------------------------------------
Django utilise un ORM avec une syntaxe séduisante au premier abord (par exemple: latest_poll_list = Poll.objects.all().order_by('- pub_date')[:5]), mais qui devient rapidement inextricable ou complètement inefficace pour une véritable application qui demande de s requêtes non triviales. CubicWeb dispose de son propre langage d'interrogation, RQL, qui reprend à l'identique les noms utilisés dan s
CubicWeb possède toutefois également son propre ORM.
Une autre force de CubicWeb, c'est son modèle de sécurité qui permet de définir des règles d'accès très évoluées, basées notamment su r des expressions RQL, aussi bien en écriture qu'en lecture sur des types d'entités, des types de relations et même des attributs d'entités :
http://www.cubicweb.org/doc/en/B0010-define-schema.en.html#the-security-mod el
Cordialement, Adrien.
Bonjour,
Je voudrais juste rajouter brièvement quelques compléments
d'information
à ce qu'a dit Nicolas dans son précédent message.
Stockage des données
---------------------------------
Django utilise une base SQL pour le stockage et cubicweb a besoin d'au
moins une base SQL (sqlite, postgresql, mysql) pour fonctionner, mais
peut aussi utiliser des données qui sont dans un annuaire LDAP et dans
un entrepôt subversion ou mercurial (voir plus bas interrogation des
données).
Une application CubicWeb est également capable d'interroger une autre
application
CubicWeb pour peu que les deux applications aient une partie de leur
définition
de schéma en commun. Il suffit alors de rajouter la seconde
application comme
étant une source de données possible et les requêtes iront interroger
cette seconde
application de manière transparente.
Interrogation des données
-------------------------------------
Django utilise un ORM avec une syntaxe séduisante au premier abord
(par exemple: latest_poll_list = Poll.objects.all().order_by('-
pub_date')[:5]), mais qui devient rapidement inextricable ou
complètement inefficace pour une véritable application qui demande de s
requêtes non triviales. CubicWeb dispose de son propre langage
d'interrogation, RQL, qui reprend à l'identique les noms utilisés dan s
CubicWeb possède toutefois également son propre ORM.
Une autre force de CubicWeb, c'est son modèle de sécurité qui permet
de
définir des règles d'accès très évoluées, basées notamment su r des
expressions
RQL, aussi bien en écriture qu'en lecture sur des types d'entités, des
types
de relations et même des attributs d'entités :
http://www.cubicweb.org/doc/en/B0010-define-schema.en.html#the-security-mod el
Je voudrais juste rajouter brièvement quelques compléments d'information à ce qu'a dit Nicolas dans son précédent message.
Stockage des données ---------------------------------
Django utilise une base SQL pour le stockage et cubicweb a besoin d'au moins une base SQL (sqlite, postgresql, mysql) pour fonctionner, mais peut aussi utiliser des données qui sont dans un annuaire LDAP et dans un entrepôt subversion ou mercurial (voir plus bas interrogation des données).
Une application CubicWeb est également capable d'interroger une autre application CubicWeb pour peu que les deux applications aient une partie de leur définition de schéma en commun. Il suffit alors de rajouter la seconde application comme étant une source de données possible et les requêtes iront interroger cette seconde application de manière transparente.
Interrogation des données -------------------------------------
Django utilise un ORM avec une syntaxe séduisante au premier abord (par exemple: latest_poll_list = Poll.objects.all().order_by('- pub_date')[:5]), mais qui devient rapidement inextricable ou complètement inefficace pour une véritable application qui demande de s requêtes non triviales. CubicWeb dispose de son propre langage d'interrogation, RQL, qui reprend à l'identique les noms utilisés dan s
CubicWeb possède toutefois également son propre ORM.
Une autre force de CubicWeb, c'est son modèle de sécurité qui permet de définir des règles d'accès très évoluées, basées notamment su r des expressions RQL, aussi bien en écriture qu'en lecture sur des types d'entités, des types de relations et même des attributs d'entités :
http://www.cubicweb.org/doc/en/B0010-define-schema.en.html#the-security-mod el
