[ANN] publication de CubicWeb 3.0.0

Le
nchauvat (Logilab)
L'équipe de développement de CubicWeb a le plaisir de vous annoncer la
publication de la version 3.0.0, surnommée ShowTime.

Qu'est-ce que CubicWeb?
--

Avec CubicWeb, le Web Sémantique devient un jeu de construction !

CubicWeb_ est une plate-forme de développement d'application web
sémantique,
disponible sous license LGPL, qui permet aux développeurs de
construire
efficacement des applications web en assemblant des composants
(appelés cubes)
et en suivant les principes bien connus de la programmation orientée-
objet.

Ses principales caractéristiques sont:

* un moteur qui utilise une représentation explicite du modèle de
données de
l'application,
* un langage de requête nommé RQL qui est semblable au SPARQL du
W3C,
* un mécanisme de sélection+vue qui permet la génération semi-
automatique de XHTML/XML/JSON/text,
* une bibliothèque de composants réutilisables (modèle de donné=
e
et vues)
qui satisfait les besoins les plus courants,
* la puissance et l'adaptabilité du langage de programmation
Python,
* la solidité des bases SQL, des annuaires LDAP, de Subversion et
Mercurial
pour le stockage des données.

Développé 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ète et éprouvée pour développ=
er
des
applications web, qui promeut la qualité, la réutilisabilité et
l'efficacité.

L'incrédule lira la présentation_ de CubicWeb.

Le développeur se joindra au projet à la forge_.

L'impatient sautera sur les consignes d'installation_.

.. _CubicWeb: http://www.cubicweb.org/
.. _présentation: http://www.cubicweb.org/doc/en/A020-tutorial.en.html#ov=
erview
.. _forge: http://www.cubicweb.org/project?vtitle=All%20cubicweb%20projec=
ts
.. _installation: http://www.cubicweb.org/doc/en/C010-setup.en.html#miseenp=
laceenv

Site Web
--

http://www.cubicweb.org/

Téléchargement
--

http://ftp.logilab.org/pub/cubicweb/

Liste de discussion
-

http://lists.cubicweb.org/mailman/listinfo/cubicweb
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
William Dode
Le #18260951
On 30-12-2008, nchauvat (Logilab) wrote:
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)
Le #18288531
Bonjour William,

On 31 déc 2008, 14:12, William Dode
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
Le #18293671
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.
Publicité
Poster une réponse
Anonyme