CubicWeb Blog

News about the framework and its uses.

show 144 results

Candidature au concours dataconnexions#2
2012/12/20 by Nicolas Chauvat
Au nom de la communauté des utilisateurs et développeurs de CubicWeb, je viens de déposer la candidature suivante au concours dataconnexions#2.

1. Questionnaire de description du Projet

Intitulé du projet

CubicWeb - plate-forme libre de développement pour le web sémantique

Catégorie de concours choisie

Choisir parmi: Grand public / Professionnel / Utilité publique / Mobilité et territoires

Utilité publique (?)

Quel problème tentez-vous de résoudre ?

Décrivez le (ou les) problème(s) que votre projet tente de résoudre, ainsi que son (leur) importance : taille du marché, fréquence d’utilisation potentielle, population concernée, bénéfices éventuels de service public, etc. (maximum 1000 signes).

L'avènement du web sémantique et de l'Open Data nécessite de disposer d'outils adaptés pour développer des applications centrées sur les données.

Ces outils doivent permettre d'importer des données facilement, de les mettre en relation lorsqu'elles proviennent de sources disjointes, de les republier et de faciliter leur interrogation et leur visualisation.

Idéalement, ces outils doivent utiliser et respecter les standards ouverts d'internet afin de simplifier les communications et les échanges, mais aussi faciliter le développement pour les terminaux multiples (ordinateur, tablette, smartphone).

Comment tentez-vous de le résoudre ?

Décrivez votre produit, service ou visualisation, dans sa forme actuelle et le cas échéant après les développements futurs éventuels que vous envisagez. Précisez le ou les jeux de données publiques que vous utilisez à cet effet (maximum 1000 signes).

CubicWeb est une plate-forme libre de développement pour le web sémantique.

CubicWeb permet aux développeurs de se concentrer sur les spécificités de leur application plutôt que d'avoir à réinventer les briques essentielles de l'import, la fusion, la publication, l'interrogation et la visualisation de données.

CubicWeb est un logiciel libre développé ouvertement sur internet par une communauté réduite mais déjà internationale. CubicWeb est disponible sous licence LGPL, respecte les standards du W3C (RDF, SPARQL, HTML5, CSS3, Responsive Design) et sait gérer nativement plusieurs modèles de données faisant office de standards de fait (FOAF, SIOC, DOAP, etc).

Quel est votre modèle d’affaire ?

Décrivez le modèle d’affaire de votre projet, c’est-à-dire les conditions de sa pérennité et de son développement : plan d’affaires et projections commerciales dans le cas d’un projet entrepreneurial ; objectifs, donneurs clés, partie prenantes dans le cas d’un projet d’ordre civique (maximum 1000 signes).

Plusieurs sociétés commerciales s'appuient aujourd'hui sur CubicWeb pour vendre des services informatiques. L'objectif de cette communauté est de croître pour bénéficier d'une audience plus large et d'une mutualisation plus importante des coûts de maintenance et de développement de la plate-forme CubicWeb.

Parmi les utilisateurs de CubicWeb, on compte à ce jour la Bibliothèque nationale de France, EDF, GDF-Suez, le Commissariat à l'Energie Atomique, le Centre National d'Etudes Spatiales, l'Institut Radioprotection et Sûreté Nucléaire, l'INRIA, des laboratoires de recherche médicale et des entreprises du domaine informatique.

Quel est l’état d’avancement de votre projet ?

Décrivez les étapes que vous avez franchies, les ressources mobilisées, les indicateurs et métriques déjà établies, etc. (maximum 1000 signes).

Le projet CubicWeb est issu d'un effort de R&D commencé en 2001 par la société Logilab, qui avait comme objectif de se doter d'un outil permettant le développement d'applications centrées sur les données et respectant les standards du web sémantique en cours d'élaboration au W3C.

Depuis 2008, CubicWeb est un logiciel libre dont le développement est mené ouvertement sur internet.

Qui vous accompagne sur ce projet ?

Décrivez l’équipe qui vous accompagne dans votre projet (le cas échéant), vos compétences, expériences et réalisations, ainsi que les partenaires éventuels qui vous soutiennent (maximum 1000 signes).

N/A.

Comment DataConnexions peut-il vous aider ?

Détaillez toutes les précisions additionnelles que vous souhaiteriez apporter au sujet de votre projet, et expliquez en quoi DataConnexions peut contribuer à pérenniser son développement (maximum 1000 signes).

Plusieurs sociétés commerciales s'appuient aujourd'hui sur CubicWeb pour vendre des services informatiques. Les utilisations industrielles de CubicWeb sont variées et concernent des applications importantes, voire critiques.

CubicWeb est un outil peu (re)connu et sa communauté est aujourd'hui réduite, malgré ses solides références et le récent engouement pour l'Open Data.

DataConnexions pourrait être une tribune et une vitrine permettant à CubicWeb de trouver de nouveaux développeurs d'applications préférant bénéficier de l'expérience capitalisée dans cet outil libre plutôt que de rédécouvrir et déjouer un par un les pièges rencontrés au cours des dix ans qui ont été nécessaires à sa réalisation.

L'objectif de cette candidature est donc de faire croître la communauté des utilisateurs et contributeurs de CubicWeb.

2. Vidéo de présentation

Lien permettant de télécharger une vidéo décrivant le Projet et ses fonctionnalités, d’une durée maximale de 3 minutes

Ce n’est pas la qualité de la vidéo qui est jugée, mais le projet lui-même. La vidéo doit permettre de rendre compte des fonctionnalités du projet. Les candidats sont encouragés à réaliser une capture d’écran ou un « screencast » (par exemple avec des outils tels que CamStudio, Jing ou Screenr).

Démonstration de l'utilisation de CubicWeb pour importer et visualiser la liste des gares françaises téléchargée depuis data.gouv.fr. Sélection des gares par le filtre à facettes et affichage sur fond de carte openstreetmap, puis export en RDF, JSON et CSV.

CubicWeb est une plate-forme libre de développement pour le web sémantique, qui permet aux développeurs de se concentrer sur les spécificités de leur application plutôt que d'avoir à réinventer les briques essentielles de l'import, la fusion, la publication, l'interrogation et la visualisation de données.

Lien vers vidéo sur youtube. Miroir de la vidéo sur vimeo.com.

3. Accès en ligne au projet

Lien permettant d’accéder au Projet, ou au code informatique compilé et interprétable du Projet

Par exemple : URL permettant de consulter, ou, le cas échéant, de télécharger l’application, accompagnée, si nécessaire, d’instructions à cet effet. L’application devra être facile à installer et aisément démontrable sur sa plateforme de destination.

http://www.cubicweb.org

4. Supports de communication

Description Non Confidentielle

Décrivez le Projet dans des termes compatibles avec une diffusion au grand public : non confidentiels, compréhensibles par le plus grand nombre, et mettant en avant l’intérêt du projet (maximum 1000 signes).

cf "comment tentez-vous de le résoudre"

Elément visuel de description

Lien vers un élément visuel décrivant et mettant en valeur le projet et ses fonctionnalités (capture d’écran, page d’accueil, schéma de description).

Logo du projet

Lien vers le logo du projet.

0 Comment | tagged by concours, dataconnexions, etatlab, opendata, screencast, video | blogged in CubicWeb Blog
Links roundup from dotjs.eu
2012/12/05 by Arthur Lutz
A few people from Logilab attended the dotjs conference in Paris last week. The conference wasn't exactly what we expected, we were hoping for more technical talks. Nevertheless, some of the things we saw were quite interesting. Some of them could be relevant to CubicWeb.

Here is a raw roundup of links collected last friday :

Chrome developer tools yeoman grunt.js backbone.js Dart TypeScriptLang Express.js Mocha Testacular SASS Angular.js Enyo.js Socket.io when.js Coffeescript Source Maps explained

0 Comment | tagged by dotjs, dotjs2012, front end, javascript, nodejs | blogged in CubicWeb Blog
CubicWeb sprint in Paris - 2012/12/13-14
2012/11/11 by Nicolas Chauvat
Topics

To be decided. Some possible topics are :
- Work on CubicWeb front end : Anything related to Themaintemplate, primaryview, reledit, tables handling etc.
- Share the Evolution and more integration of the OrbUI project for CW
- Things to do for HTML5 and bootstrap integration
- Work on ideas from Thoughts on CubicWeb 4
- ...
other ideas are welcome, please bring them up on cubicweb@lists.cubicweb.org
Location

This sprint will take place in decembre 2012 from thursday the 13th to friday the 14th. You are more than welcome to come along, help out and contribute. An introduction is planned for newcomers.

Network resources will be available for those bringing laptops.

Address : 104 Boulevard Auguste-Blanqui, Paris. Ring "Logilab" (googlemap)

Metro : Glacière

Contact : http://www.logilab.fr/contact

Dates : 13/12/2012 to 14/12/2012
Participants
- Celso Flores (Crealibre - Mexico)
- Carine Fourrier (Crealibre - Mexico)
- ...
0 Comment | tagged by announce, cubicweb, event, sprint, sprint_feb_2012 | blogged in CubicWeb Blog
Building your URLs in cubicweb
2012/09/25 by Stéphane Bugat
Building your URLs in cubicweb

Aim

In cubicweb, you often have to build url's that redirect the current view to a specific entity view or allow the execution of a given action. Moreover, you often want also to fallback to the previous view once the specific action or edition is done, or redirect also to another entity's specific view.

To do so, cubicweb provides you with a set of powerful tools, however as there is often more than one way to do it, this blog entry is here to help you in choosing the preferred way.
Tools at your disposal
The universal URL builder: build_url()

build_url is accessible in any context, so for instance in the rendering of a given entity view you can call self._cw.build_url to build you URLs easily, which is the most common case. In class methods (for instance, when declaring the rendering methods of an EntityTableView), you can access it through the context of instantiated appobject which are usually given as argument, e.g. entity._cw.build_url. For test purposes you can also call session.build_url in cubicweb shells.

build_url basically take a first optional, the path, relative to the base url of the site, and arbitrary named arguments that will be encoded as url parameters. Unless you wish to direct to a custom controller, or to match an URL rewrite url, you don't have to specify the path.

Extra parameters given to build_url will vary according to your needs, however most common arguments understood by default cubicweb views are the followings:

vid: the built view __regid__;

rql: the RQL query used to retreive data on which the view should be applied;

eid: the identifier of an entity, which you should use instead of rql when the view apply to a single entity (most often);

__message: an information message to display inside the view;

__linkto: in case of an entity creation url, will allow to set some specific relations between both entities;

__redirectpath: the URL of the entity of the redirection;

__redirectvid: the view id of the redirection.

__redirectvid and __redirectpath are used to control redirection after posting a form and are more detailed in the cubicweb documentation, chapter related to the edition control (http://docs.cubicweb.org/devweb/edition/editcontroller.html).
Exploring entities associated URLs

Generally, an entity has two important methods that retrieve its absolute or relative urls:

entity.rest_path() will return something like <type>/<eid> where <type> corresponds to the entity type and <eid> the entity eid;

entity.absolute_url() will return the full url of the entity http://<baseurl>/<type>/<eid>. In case you want to access a specific view of the entity, just pass the vid='myviewid' argument. You can give arbitrary arguments to this method that will be encoded as url parameters.
Getting a proper RQL

Passing the rql to the build_url method requires to have a proper RQL expression. To do so, there is a convenience method, printable_rql(), that is accessible in rset resulting from RQL queries. This allows to apply a view to the same result set as the one currently process, simply using rql = self.cw_rset.printable_rql().
Getting URLs from the current view

There are several ways to get URL of the current view, the canonical one being to use self._cw.relative_path(includeparams=True) which will return the path of the current view relative to the base url of the site (otherwise use self._cw.url(), including parameters or not according to value given as includeparams).

You can also retrieve values given to individual parameters using self._cw.form, eg:

self._cw.form.get('vid', '') will return only the view id;

self._cw.form.get('rql', '') will return only the RQL;

self._cw.form.get('__redirectvid', '') will return the redirection view if defined;

self._cw.form.get('__redirectpath', '') will return the redirection path if defined.
How to redirect to non-entity view?

This case often appears when you want to create a link to a startup view or a controller. It the first case, you simply build you URL like this:
```
self._cw.build_url('view', vid='my_view_id')
```
The latter case appears when you want to call a controller directly without having to define a form in your view. This can happen for instance when you want to create a URL that will set a relation between 2 objects and do not need any confirmation for that. The URL construction is done like this:
```
self._cw.build_url('my_controller_id', arg1=value1, arg2=value2, ...)
```
Any extra arguments passed to the build_url method will be available in the controller as key, values pairs of the self._cw.forms dictionary. This is especially useful when you want to define some kind of hidden attributes but there is not form to put them into.

And, last but not least, a convenient way to get the root URL of the instance:
```
self._cw.base_url()
```
How to link to a registered action?

There are other ways to create a link to registered actions than using build_url, mostly by accessing them via the registry vreg.

For instance, the action registry holds effectively all possible actions in a given context: a specific action can be selected using the select_or_none() method, or even using the possible_action() method which will return a list of categorized actions. The url of the action is then available as action.url(). For contextual components (e.g. boxes), you can even directly get a link to the selected action(s) using the self.action_link(this_action) method.

If the action corresponds to the creation of a new entity, there is an even faster and elegant way to do it, using the schema of your cube:
```
url = self._cw.vreg["etypes"].etype_class('MyEntity').cw_create_url(self._cw)
```
Some concrete cases

Get the URL of the outofcontext view of an entity:
```
link = entity.absolute_url(vid='outofcontext')
```
Create a link to a given controller then fall back to the current view:
- In your entity view:
```
self.w(u'<a href="%s">Click me</a>' % xml_escape(
        self._cw.build_url('mycontrollerid',
                arg1=value1, arg2=value2,
                rql=self.cw_rset.printable_rql(),
                __redirectvid=self._cw.form.get('vid',''))))
```
- In your controller:
```
def publish(self, rset):
     value1, value2 = self._cw.form['arg1'], self._cw.form['arg2']
     # do some stuff with value1 and value2 here...
     raise Redirect(self._cw.build_url(rql=self._cw.form['rql'],
         vid=self._cw.form['__redirectvid'],
         __message=_('you message')))
```
Create a link to add a given entity and relate this entity to the current one with a relation 'child_of', then go back to the current entity's view:
```
entity = self.cw_rset.get_entity(0,0)
self.w(u'<a href="%s">Click me</a>' % xml_escape(
        self._cw.build_url('add/Mychildentity',
                __linkto='child_of:%s:object' % entity.eid,
                __redirectpath=entity.rest_path(),
                __redirectvid=self._cw.form.get('vid', ''))))
```
Same example, but we suppose that we are in a multiple rset entity view, and we want to go back afterwards to this view:
```
entity = self.cw_rset.get_entity(0,0)
self.w(u'<a href="%s">Click me</a>' % xml_escape(
        self._cw.build_url('add/Mychildentity',
                rql=self.cw_rset.printable_rql(),
                __linkto='child_of:%s:object' % entity.eid,
                __redirectvid=self._cw.form.get('vid', ''))))
```
Create links to all 'menuactions' in a view:
```
actions = self._cw.vreg['actions'].possible_actions(self._cw, rset=self.cw_rset)
action_links = [unicode(self.action_link(x)) for x in actions.get('menuactions', ())]
self.w( u'  |  '.join(action_links))
```
0 Comment | tagged by nicer_url | blogged in CubicWeb Blog
How to create your own forms and controllers?
2012/09/05 by Stéphane Bugat
Aim

Sometimes you need to associate to a given view your own specific form and the associated controller. We will see in this blog entry how it can be done in cubicweb on a concrete case.
The case

Let's suppose you're working on a social network project where you have to develop friend-of-a-frient (foaf) relationships between persons. For that purpose, we use the cubicweb-person cube and create in our scheme relations between persons like X in_contact_with Y:
```
class in_contact_with(RelationDefinition):
      subject = 'Person'
      object = 'Person'
      cardinality = '**'
      symmetric = True
```
We will also assume that a given Person corresponds to a unique CWUser through the relation is_user.

Although it is not evident, we would like that any connected person can chose to disconnect himself from another person at any time. For that, we will create a table view that will display the list of connected users, with a custom column giving the ability to "disconnect" with the person.

Before disconnecting with this particular person, we would like also to have a confirmation form.
How to proceed

The following steps were defined to address the above issue:
1. Define a "contact view" that will display the list of known contacts of the connected user ;
2. In this contact view, allow the user to click on a specific contact so as to remove him ;
3. Create a deletion confirmation view, that will contain:
  
  A form holding the buttons for deletion confirmation or cancel;
  
  A controller responsible for the actual deletion or the cancelling.
The contact view
Rendering a table view of connected persons

To display the list of connected persons to the current person, but also to add custom columns that do not refer specifically to attributes of a given entity, the best choice is to use EntityTableView (see here for more information):

class ContactView(EntityTableView): __regid__ = 'contacts_tableview' __select__ = is_instance('Person') columns = ['person', 'firstname', 'surname', 'email', 'phone', 'remove'] layout_args = {'display_filter': 'top', 'add_view_actions': None} def cell_remove(w, entity): """link to the suppression of the relation between both contacts""" icon_url = entity._cw.data_url('img/user_delete.png') action_url = entity._cw.build_url(eid=entity.eid, vid='suppress_contact_view', __redirectpath=entity._cw.relative_path(), __redirectvid=entity._cw.form.get('__redirectvid', '')) w(u'<a href="%(actionurl)s" title="%(title)s">' u'<img alt="%(title)s" src="%(url)s" /></a>' % {'actionurl': xml_escape(action_url), 'title': _('remove from contacts'), 'url':icon_url}) column_renderers = { 'person': MainEntityColRenderer(), 'email': RelatedEntityColRenderer( getrelated=lambda x:x.primary_email and x.primary_email[0] \ or None), 'phone': RelatedEntityColRenderer( getrelated=lambda x:x.phone and x.phone[0] or None), 'remove': EntityTableColRenderer( renderfunc=cell_remove, header=''),}

A few explanations about the above view:

By default, the column attribute contains a list of displayable attributes of the entity. If one element of the list does not correspond to an attribute, which is the case for 'remove' here, it has to have rendering function defined in the dictionnary column_renderers.

However, when the column header refers to a related entity attribute, we can easily use the rendering function RelatedEntityColRenderer, as it is the case for the email and phone display.

As for concerns the 'remove' column, we render a clickable image in the cell_remove method. Here we have chosen an icon from famfamsilk that is putted in our data/ directory, but feel free to chose a predefined icon in the cubicweb shared data directory.

The redirection URL associated to each image has to be a link to a specific action allowing the user to remove the selected person from its contacts. It is built using the self._cw.build_url() convenience function. The redirection view, 'suppress_contact_view', will be defined later on. The eid argument passed refers to the id of the contact person the user wants to remove.
Calling the contact view

The above view has to be called with a given rset which corresponds to the list of known contacts for the connected user. In our case, we have defined a StartupView for the contact management, in which in the call function we have added the following piece of code:

person = self._cw.user.related('is_user', 'object').get_entity(0,0) rset = self._cw.execute( 'Any X WHERE X is Person, X in_contact_with Y, ' 'Y eid %(eid)s', {'eid': person.eid}) self.w(u'<h3>' + _('Number of contacts in my network:')) self.w(unicode(len(rset)) + u'</h3>') if len(rset) != 0: self.wview('contacts_tableview', rset)

The Person corresponding to the connected user is retrieved thanks to the use of the related method and the is_user relation. The contact table view is displayed inside the parent StartupView.
Creation of the deletion confirmation view
Defining the confirmation view for contact deletion

The corresponding view is a simple View class instance, that will display a confirmation message and the related buttons. It could be defined as follows:

class SuppressContactView(View): __regid__ = 'suppress_contact_view' def cell_call(self, row, col): entity = self.cw_rset.get_entity(row, col) msg = self._cw._('Are you sure you want to remove %(name)s from your contacts?') self.w(u'<p>' + msg % {'name': entity.dc_long_title()} + u'</p>') form = self._cw.vreg['forms'].select('suppress_contact_form', self._cw, rset=self.cw_rset) form.add_hidden(u'eidto', entity.eid) form.add_hidden(u'eidfrom', self._cw.user.related('is_user', 'object').get_entity(0,0).eid) form.render(w=self.w)

Inside the cell_call() method of this view, we will have to render a form which aims at displaying both buttons (confirm deletion or cancel deletion). This form will be described later on.

The Person contact to remove is retrieved easily thanks to cw_rset. The Person corresponding to the connected user is here also retrieved thanks to the is_user relation. To make both of them available in the form, we add them at the instanciation of the form using the convenience function add_hidden(key,val).
Defining the deletion form

The deletion form as mentioned previously is only here to hold both buttons for the deletion confirmation or the cancelling. Both buttons are declared thanks to the form_buttons attribute of the form, which is instanciated from forms.FieldsForm:

class SuppressContactForm(forms.FieldsForm): __regid__ = 'suppress_contact_form' domid = 'delete_contact_form' form_renderer_id = 'base' @property def action(self): return self._cw.build_url('suppress_contact_controller') form_buttons = [ fw.Button(stdmsgs.BUTTON_DELETE, cwaction='delete'), fw.Button(stdmsgs.BUTTON_CANCEL, cwaction='cancel')]

Specifying a given domid will ensure that your form will have a specific DOM identifier,the controller defined in the action method will be called without any ambiguity. The form_renderer_id is precised here so as to avoid additional display of informations which don't make sense here.
Defining the controller

The custom controller is instanciated from the Controller class in cubicweb.web.controller. The declaration of the controller should have the same domid than the calling form, as mentioned previously. The related actions are described in the publish() method of the controller:

class SuppressContactController(Controller): __regid__ = 'suppress_contact_controller' domid = 'delete_contact_form' def publish(self, rset=None): if '__action_cancel' in self._cw.form.keys(): msg = self._cw._('Deletion canceled') raise Redirect(self._cw.build_url( vid='contact_management_view', __message=msg)) elif '__action_delete' in self._cw.form.keys(): xid = self._cw.form['eidfrom'] dead_contact = self._cw.entity_from_eid(xid) yid = self._cw.form['eidto'] self._cw.execute( 'DELETE X in_contact_with Y' ' WHERE X eid %(xid)s, Y eid %(yid)s', {'xid': xid, 'yid': yid}) msg = self._cw._('%s removed from your contacts') %\ dead_contact.dc_long_title() raise Redirect(self._cw.build_url( vid='contact_management_view', __message=msg))

Retrieving of the user action is performed by testing if the '__action_<action>', where <action> refers to the cwaction in the button declaration, is present in the form keys. In the case of a cancelling, we simply redirect to the contact management view with a message specifying that the deletion has been cancelled. In the case of a deletion confirmation, both Person id's for the connected user and for the contact to remove are retrieved from the form hidden arguments.

The deletion is performed using an RQL request on the relation in_contact_with. We also redirect the view to the contact management view, this time with another message confirming the deletion of the contact link.
0 Comment | blogged in CubicWeb Blog
Logilab at the LawFactory
2012/07/16 by Vincent Michel
We have been playing along with political data for a while, using CubicWeb to store and query various sets of open data (e.g. NosDeputes, data.gouv.fr), and testing different visualization tools. In particular, we have extended our prototype of News Analysis (see the presentation we made last year at Euroscipy), in order to use these political datasets as reference for the named entities extraction part. Last week's conference "The Law Factory" at Sciences Po was a really nice opportunity to meet people with similar interests in opendata for political sciences, and to find out which questions we should be asking our data ! Check out the talk of our presentation and a few screencasts (no sound) :
Comments are welcome !
Interresting things seen at #OLPC

Among the different things that we have seen, we want to emphasize on:
- Law is Code (http://gitorious.org/law-is-code/) - This project by the team of Regards Citoyens, aims at analysing the laws and amendments, by extracting information from the French National Assembly website, and by pushing the contributions of the members of parlement to a given law in a git repository. If we can find the time, we'll turn that into a mercurial repository and integrate it into our above application using cubicweb-vcsfile.
- Both national websites (Assemblée Nationale, Sénat), do not allow (yet...) to get data any other way than parsing the sites. However, it seems that the people involved are aware of the issues of opendata, and this may changed in the next months. In particular, the Senat use two databases (Basile and Ameli), and opening them to the public could be really interesting
- Different projects about African parlements can be found on the following website : http://www.parliaments.info
- Check out, ITCparliement which gives tools to analyse and share data from many different parliments.
Saturday, at La Cantine Numérique, the discussions focused on the possibilities to share tools, and the possible collaborations. I think that this is the crucial point: How people can share tools and use them in a efficient way, without being an IT expert ?
How does this inspire us for CubicWeb ?

In this way, we have are thinking about some evolutions of CubicWeb that can fullfill (part) of these requirements:
- easier installation, especially on Windows, and easier Postgresql configuration. This could perhaps be made by allowing some graphical interface for creating/managing the instances and the databases.
- a graphical tool for schema construction. Even if the construction of a data model in CubicWeb is quite simple, and rely on the straightforward Python syntax, it could be interesting to expose a graphical tool for adding/removing/modifying entities from the schema, as well as some attributes or relations.
- easier ways to import data. This point is not trivial, and we don't want to develop a specific language for defining import rules, that could be used for 80% of the cases, but will be painful to extend to the 20% exotic cases. We would rather develop some helpers to ease the building of some import scripts in Python, and to upload some CubicWeb instances already filled with open databases.
Demo of CubicWeb as a follow up

As a follow up of the conference, we are openning a demo site using CubicWeb to expose data of the past legislative and presidential elections (2002, 2007, 2012)

The data used is published under Licence Ouverte / Open Licence by http://data.gouv.fr.

This demo site allows you to deeply explore the data, with different visualisations, and complex queries. Again, comments are welcome, especially if you want to retrieve some information but you don't know how to! This demo site will probably evolve in the next weeks, and we will use it to test different cubes that we have been building.

PS: We are sorry we cannot open the propotype of news aggregator for now, as there are still licensing issues concerning the reusability of the different news sources that we get articles from.
0 Comment | tagged by elections, la fabrique de la loi, law factory, olpc, opendata | blogged in CubicWeb Blog
What's new in CubicWeb 3.15
2012/05/14 by Sylvain Thenault
CubicWeb 3.15 introduces a bunch of new functionalities. In short (more details below):
- ability to use ZMQ instead of Pyro to connect to repositories
- ZMQ inter-instances messages bus
- new LDAP source using the datafeed approach, much more flexible than the legacy 'ldapuser' source
- full undo support
Plus some refactorings regarding Ajax function calls, WSGI, the registry, etc. Read more for the detail.
New functionalities
- Add ZMQ server, based on the cutting edge ZMQ socket library. This allows to access distant instances, in a similar way as Pyro.
- Publish/subscribe mechanism using ZMQ for communication among cubicweb instances. The new zmq-address-sub and zmq-address-pub configuration variables define where this communication occurs. As of this release this mechanism is used for entity cache invalidation.
- Improved WSGI support. While there are still some caveats, most of the code which was twisted only is now generic and allows related functionalities to work with a WSGI front-end.
- Full undo/transaction support: undo of modifications has finally been implemented, and the configuration simplified (basically you activate it or not on an instance basis).
- Controlling HTTP status code returns is now much easier:
  
  WebRequest now has a status_out attribute to control the response status ;
  
  most web-side exceptions take an optional status argument.
API changes
- The base registry implementation has been moved to a new logilab.common.registry module (see #1916014). This includes code from :
  
  cubicweb.vreg (everything that was in there)
  
  cw.appobject (base selectors and all).
  
  In the process, some renaming was done:
  
  the top level registry is now RegistryStore (was VRegistry), but that should not impact CubicWeb client code;
  
  former selectors functions are now known as "predicate", though you still use predicates to build an object'selector;
  
  for consistency, the objectify_selector decorator has hence been renamed to objectify_predicate;
  
  on the CubicWeb side, the selectors module has been renamed to predicates.
  
  Debugging refactoring dropped the need for the lltrace decorator. There should be full backward compat with proper deprecation warnings. Notice the yes predicate and objectify_predicate decorator, as well as the traced_selection function should now be imported from the logilab.common.registry module.
- All login forms are now submitted to <app_root>/login. Redirection to requested page is now handled by the login controller (it was previously handled by the session manager).
- Publisher.publish has been renamed to Publisher.handle_request. This method now contains a generic version of the logic previously handled by Twisted. Controller.publish is not affected.
Unintrusive API changes
- New 'ldapfeed' source type, designed to replace 'ldapuser' source with data-feed (i.e. copy based) source ideas.
- New 'zmqrql' source type, similar to 'pyrorql' but using ømq instead of Pyro.
- A new registry called 'services' has appeared, where you can register server-side cubicweb.server.Service child classes. Their call method can be invoked from a web-side AppObject instance using the new self._cw.call_service method or a server-side one using self.session.call_service. This is a new way to call server-side methods, much cleaner than monkey patching the Repository class, which becomes a deprecated way to perform similar tasks.
- a new ajaxfunction registry now hosts all remote functions (i.e. functions callable through the asyncRemoteExec JS api). A convenience ajaxfunc decorator will let you expose your python functions easily without all the appobject standard boilerplate. Backwards compatibility is preserved.
- the 'json' controller is now deprecated in favor of the 'ajax' one.
- WebRequest.build_url can now take a __secure__ argument. When True, cubicweb tries to generate an https url.
User interface changes

A new 'undohistory' view exposes the undoable transactions and gives access to undo some of them.
1 Comment | tagged by announce, cubicweb, cw3.15, release, undo, zmq | blogged in CubicWeb Blog
Thoughts on CubicWeb 4.0
2012/05/14 by Sylvain Thenault
This is a fairly technical post talking about the structural changes I would like to see in CubicWeb's near future. Let's call that CubicWeb 4.0! It also drafts ideas on how to go from here to there. Draft, really. But that will eventually turn into a nice roadmap hopefully.
The great simplification

Some parts of cubicweb are sometimes too hairy for different reasons (some good, most bad). This participates in the difficulty to get started quickly. The goal of CubicWeb 4.0 should be to make things simpler :
- Fix some bad old design.
- Stop reinventing the wheel and use widely used libraries in the Python Web World. This extends to benefitting from state of the art libraries to build nice and flexible UI such as Bootstrap, on top of the JQuery foundations (which could become as prominent as the Python standard library in CubicWeb, the development team should get ready for it).
- If there is a best way to do something, just do it and refrain from providing configurability and options.
On the road to Bootstrap

First, a few simple things could be done to simplify the UI code:
- drop xhtml support: always return text/html content type, stop bothering with this stillborn stuff and use html5
- move away everything that should not be in the framework: calendar?, embedding, igeocodable, isioc, massmailing, owl?, rdf?, timeline, timetable?, treeview?, vcard, wdoc?, xbel, xmlrss?
Then we should probably move the default UI into some cubes (i.e. the content of cw.web.views and cw.web.data). Besides making the move to Bootstrap easier, this should also have the benefit of making clearer that this is the default way to build an (automatic) UI in CubicWeb, but one may use other, more usual, strategies (such as using a template language).

At a first glance, we should start with the following core cubes:
- corelayout, the default interface layout and generic components. Modules to backport there: application (not an appobject yet), basetemplates, error, boxes, basecomponents, facets, ibreadcrumbs, navigation, undohistory.
- coreviews, the default generic views and forms. Modules to backport there: actions, ajaxedit, baseviews, autoform, dotgraphview, editcontroller, editforms, editviews, forms, formrenderers, primary, json, pyviews, tableview, reledit, tabs.
- corebackoffice, the concrete views for the default back-office that let you handle users, sources, debugging, etc. through the web. Modules to backport here: cwuser, debug, bookmark, cwproperties, cwsources, emailaddress, management, schema, startup, workflow.
- coreservices, the various services, not directly related to display of something. Modules to backport here: ajaxcontroller, apacherewrite, authentication, basecontrollers, csvexport, idownloadable, magicsearch, sessions, sparql, sessions, staticcontrollers, urlpublishing, urlrewrite.
This is a first draft that will need some adjustements. Some of the listed modules should be split (e.g. actions, boxes,) and their content moved to different core cubes. Also some modules in cubicweb.web packages may be moved to the relevant cube.

Each cube should provide an interface so that one could replace it with another one. For instance, move from the default coreviews and corelayout cube to bootstrap based ones. This should allow a nice migration path from the current UI to a Bootstrap based UI. Bootstrap should probably be introduced bottom-up: start using it for tables, lists, etc. then go up until the layout defined in the main template. The Orbui experience should greatly help us by pointing at hot spots that will have to be tackled, as well as by providing a nice code base from which we should start.

Regarding current implementation, we should take care that Contextual components are a powerful way to build "pluggable" UI, but we should probably add an intermediate layer that would make more obvious / explicit:
- what the available components are
- what the available slots are
- which component should go in which slot when possible
Also at some point, we should take care to separate view's logic from HTML generation: our experience with client works shows that a common need is to use the logic but produce a different HTML. Though we should wait for more use of Bootstrap and related HTML simplification to see if the CSS power doesn't somewhat fulfill that need.
On the road to WSGI and related

For the record regarding WSGI:
At some point, the whole cw.etwist package should be dropped in favor of cw.wsgi.
Werkzeug

http://werkzeug.pocoo.org/

The Werkzeug framework sounds like a good candidate to use as a library that would replace/simplify the request, httpcache, session, authentication (maybe more) modules as well as the wsgi package. It sounds like the right candidate for the following reasons:

it's a non-intrusive WSGI library, not a web framework,

it's used by fairly popular frameworks (openerp, flask),

I'm +1 on A. Ronacher idea of a common request implementation for python web frameworks, let's experiment and promote this idea.
Route (URL handling)

Investigate URL routing modules as a replacement for urlpublishing, urlrewrite and apacherewrite.

Candidates are :

werkzeug.routing, which has noticable pros: celebrated by A. Martelli, provided by an already-in-wishlist library, URL routing AND generation.

routes (http://routes.readthedocs.org/en/latest/), pros: used by pylons, features conditional matching based on domain, cookies, HTTP method... and sub-domain support.

selector (http://lukearno.com/projects/selector/)

I've to say I'm somewhat impatient to find some time to give a try to werkzeug.routing. IMO, used well, that may introduce a structural change that would make things much easier to understand and configure properly.
On the road to proper tasks management

The current looping task / repo thread mecanism is used for various sort of things and has several problems:
- tasks don't behave similarly in a multi-instances configuration (some should be executed in a single instance, some in a subset); the tasks system has been originally written in a single instance context; as of today this is (sometimes) handled using configuration options (that will have to be properly set in each instance configuration file);
- tasks is a repository only api but we also need web-side tasks;
- there is probably some abuse of the system that may lead to unnecessary resources usage.
Analyzing a sample http://www.logilab.org/ instance, below are the running looping task by categories. Tasks that have to run on each web instance:
- clean_sessions, automatically closes unused repository sessions. Notice cw.etwist.server also records a twisted task to clean web sessions. Some changes are imminent on this, they will be addressed in the upcoming refactoring session (that will become more and more necessary to move on several points listed here).
- regular_preview_dir_cleanup (preview cube), cleanup files in the preview filesystem directory. Could be executed by a (some of the) web instance(s) provided that the preview directory is shared.
Tasks that should run on a single instance:
- update_feeds, update copy based sources (e.g. datafeed, ldapfeed). Controlled by 'synchronize' source configuration (persistent source attribute that may be overridden by instance using CWSourceHostConfig entities)
- expire_dataimports, delete CWDataImport entities older than an amount of time specified in the 'logs-lifetime' configuration option. Not controlled yet.
- cleanup_auth_cookies (rememberme cube), delete CWAuthCookie entities whose life-time is exhausted. Not controlled yet.
- cleaning_revocation_key (forgotpwd cube), delete Fpasswd entities with past revocation_date. Not controlled yet.
- cleanup_plans (narval cube), delete Plan entities instance older than an amount of time specified in the configuration. If 'plan-cleanup-delay' is set to an empty value, the task isn't started.
- refresh_local_repo_caches (vcsfile cube), pull or clone vcs repositories cache if the Repository entity ask to import_revision_content (hence web instance should have up to date cache to display files content) or if 'repository-import' configuration option is set to 'yes'; import vcs repository content as entities if 'repository-import' configuration option and it is coming from the system source.
Some deeper thinking is needed here so we can improve things. That includes thinking about:
- the inter-instances messages bus based on zmq and introduced in 3.15,
- the Celery project (http://celeryproject.org/), an asynchronous task queue, widely used and written in Python,
Remember the more cw independent the tasks are, the better it is. Though we still want an 'all-integrated' approach, e.g. not relying on external configuration of Unix specific tools such as CRON. Also we should see if a hard-dependency on Celery or a similar tool could be avoided, and if not if it should be considered as a problem (for devops).
On the road to an easier configuration

First, we should drop the different behaviour according to presence of a '.hg' in cubicweb's directory. It currently changes the location where cubicweb external resources (js, css, images, gettext catalogs) are searched for. Speaking of implementation:
- shared_dir returns the cubicweb.web package path instead of the path to the shared cube,
- i18n_lib_dir returns the cubicweb/i18n directory path instead of the path to the shared/i18n cube,
- migration_scripts_dir returns the cubicweb/misc/migration directory path instead of share/cubicweb/migration.
Moving web related objects as proposed in the Bootstrap section would resolve the problem for the content web/data and most of i18n (though some messages will remain and additional efforts will be needed here). By going further this way, we may also clean up some schema code by moving cubicweb/schemas and cubicweb/misc/migration to a cube (though only a small benefit is to be expected here).

We should also have fewer environment variables... Let's see what we have today:
- CW_INSTANCES_DIR, where to look for instances configuration
- CW_INSTANCES_DATA_DIR, where to look for instances persistent data files
- CW_RUNTIME_DIR, where to look for instances run-time data files
- CW_MODE, set to 'system' or 'user' will predefine above environment variables differently
- CW_CUBES_PATH, additional directories where to look for cubes
- CW_CUBES_DIR, location of the system 'cubes' directory
- CW_INSTALL_PREFIX, installation prefix, from which we can compute path to 'etc', 'var', 'share', etc.
I would propose the following changes:
- CW_INSTANCES_DIR is turned into CW_INSTANCES_PATH, and defaults to ~/etc/cubicweb.d if it exists and /etc/cubicweb.d (on Unix platforms) otherwise;
- CW_INSTANCES_DATA_DIR and CW_RUNTIME_DIR are replaced by configuration file options, with smart values generated at instance creation time;
- the above change should make CW_MODE useless;
- CW_CUBES_DIR is to be dropped, CW_CUBES_PATH should be enough;
- regarding CW_INSTALL_PREFIX, I'm lacking experience with non-hg-or-debian installations and don't know if this can be avoided or not.
Last but not least (for the moment), the 'web' / 'repo' / 'all-in-one' configurations, and the fact that the associated configuration file changes stinks. Ideas to stop doing this:
- one configuration file per instance, with all options provided by installed parts of the framework used by the application.
- activate 'services' (or not): web server, repository, zmq server, pyro server. Default services to be started are stored in the configuration file.
There is probably more that can be done here (less configuration options?), but that would already be a great step forward.
On the road to...

The following projects should be investigated to see if we could benefit from them:
- Paste (http://pythonpaste.org/, Configuration and all)
- Beaker (http://beaker.readthedocs.org/en/latest/index.html, More on Session / cache handling than what will be found in Werkzeug?)
- Pyramid's debug toolbar (http://docs.pylonsproject.org/projects/pyramid_debugtoolbar/en/latest/). See also http://firelogger.binaryage.com/#python. Notice Werkzeug comes with an integrated js console as well.
- zc.buildout (Deployment)
Discussion

Remember the following goals: migration of legacy code should go smoothly. In a perfect world every application should be able to run with CubicWeb 4.0 until the backwards compatibility code is removed (and CubicWeb 4.0 will probably be released as 4.0 at that time).

Please provide feedbacks:
- do you think choices proposed above are good/bad choices? Why?
- do you know some additional libraries that should be investigated?
- do you have other changes in mind that could/should be done in cw 4.0?
2 Comments | tagged by bootstrap, cubicweb, jquery, mongrel2, ngxwsgi, orbui, roadmap, uwsgi | blogged in CubicWeb Blog
Follow up of IRI conference about Museums and the Web #museoweb
2012/04/12 by Arthur Lutz
I attented the conference organised by IRI in a series of conferences about "Muséologie, muséographie et nouvelles formes d’adresse au public" (hashtag #museoweb). This particular occurence was about "Le Web devient audiovisuel" (the web is also audio and video content). Here are a few notes and links we gathered. The event was organised by Alexandre Monnin @aamonnz.

Yves Raimond from the BBC

Yves Raimond @moustaki made a presentation about his work at the BBC around semantic web technologies and speech recognition over large quantities of digitized archives. Parts of the BCC web sites use semantic web data as the database and do mashups with external sources of data (musicbrainz, dbpedia, wikipedia). For example Tom Waits has an html web page : http://www.bbc.co.uk/music/artists/c3aeb863-7b26-4388-94e8-5a240f2be21b add .rdf at the end of the URL http://www.bbc.co.uk/music/artists/c3aeb863-7b26-4388-94e8-5a240f2be21b.rdf

He also made an introduction about the ABC-IP The Automatic Broadcast Content Interlinking Project and the Kiwi-API project that uses CMU Sphinx on Amazon Web Services to process large quantities of archives. A screenshot of Kiwi-API is shown on the BBC R&D blog. The code should be open sourced soon and should appear on the BBC R&D github page.

Following his presentation, the question was asked if using Wikipedia content on an institutional web site would be possible in France, I pointed to the use of Wikipedia on http://data.bnf.fr , for example at the bottom of the Victor Hugo page.
Raphaël Troncy about Media Fragments

Raphaël Troncy @rtroncy made a presentation about "Media Fragments" which will enable sharing parts of a video on the web. Two major features : the sharing of specific extracts and the optimization of bandwith use when streaming the extract (usefull for mobile devices for example). It is a W3C working draft : http://www.w3.org/TR/media-frags-reqs/. Here are a few links of demos and players :
- Temporal Media Fragment Test Builds http://www.bluishcoder.co.nz/mediafrag/
- NinSuna http://ninsuna.elis.ugent.be/
- yuma.min.js http://yuma-js.github.com/index.html a javascript framework to annotate videos on the web
Part of the presentation was about the ACAV project done jointly with Dailymotion : http://www.capdigital.com/projet-acav/

The slides of his presentation are available here : http://www.slideshare.net/troncy/addressing-and-annotating-multimedia-fragments
IRI presentation

Vincent Puig @vincentpuig and Raphaël Velt @raphv made a presentation of various projects led by IRI :
- Lignes des temps : http://ldt.iri.centrepompidou.fr/ldtplatform/ldt/ (here is an example of a conference about opendata during which I tweeted : RSLN open data )
- PolemicTweet http://polemictweet.com/
- Bubble-T visualization of tweets about the french presidential elections : http://www.iri.centrepompidou.fr/experimentations/bubble-t/
- HDA Labs http://hdalab.iri-research.org/hdalab/
Final words

The technologies seen during this conference are often related to semantic web technologies or at least web standards. Some of the visualizations are quite impressive and could mean new uses of the Web and an inspiration for CubicWeb projects.

A few of the people present at the conference will be attending or presenting talks at SemWeb.Pro which will take place in Paris on the 2nd and 3rd of may 2012.
1 Comment | tagged by iri, media fragments, presentation, semantic web, video, visualisation | blogged in CubicWeb Blog
CubicWeb Sprint report for the "BugSquash" team
2012/03/16 by Nicolas Chauvat

Beginners fixed core bugs

The first day of the CubicWeb sprint was dedicated to an introduction to a group of four beginners that included two people that do not work at Logilab. At the end of day, this team knew about Entity, Views and Schema and was ready to dive into the core in order to squash some bugs.

The first steps into the CubicWeb core were not so easy, but these brave beginners, assisted by a skilled developer, managed to fix some bugs and add a few useful features, including one from a windows user that made it into the stable branch.

The gen-static-datadir command

We had a look at cubicweb-ctl gen-static-datadir, a feature that copies in a directory all the files that could be cached by a "front" web server instead of being served by cubicweb.

Testing the feature

At first run, we found that not all files where copied. We alas were unable to reproduce. So we need to keep an eye on this. On next tests, we tried several configuration. The files that were copied were always the ones containd in the "deepest" cube in the tree of cubes. So we can say that the command is working well.

Approach used by the feature

In the code, we browse all cubes used by the master cube to gather all filenames that we want to copy and afterwards we use "config.locate_resource(resource)" to find the best location for this file.

Doing this, we sometimes copy a file from the cache. If we do not want to use the cache, we could be sort the cubes recursively copy the whole data folder and sometimes overwrite files with files located nearer to the master cube.

New option

We added a -r option that erases the target directory before launching the command.

0 Comment | blogged in CubicWeb Blog

show 144 results

Blog #1238 - latest update on 2009/09/01, created on 2008/12/22 by Nicolas Chauvat

CubicWeb Blog

Building your URLs in cubicweb