Version 3.17

This version should be published before the end of March and will finish all the things that are work in progress. It will include:

• the refactoring necessary to introduce persistant sessions,
• the shrinking of web/views: everything that does not deserve its own cube (like sioc, embed, geocoding, etc) will go into a cube named legacyui (this will open the door to squareui),
• stop serving pages with "content-type: application/xhtml",
• handling postgresql schemas (will require a new version of logilab.database),
• a new logo.

Squareui

Once the cube legacyui extracted (in version 3.17), it will be possible to move forward swiftly with squareui. Due to its other duties, one can not expect the core CW team to develop squareui. People interested will be in charge and ideally the squareui cube could be released when cubicweb 3.17 will be published.

Cleaning up the backlog

The lead CW developers will spend about 20% of their time cleaning up the ticket backlog at the forge (900 open tickets and 50 in progress !)

The first step will be to reduce the number of tickets "in progress", then to organize the open tickets and merge the duplicates.

Version 3.18

This version is due at the end of may 2013. It will include:

• persisting sessions,
• WSGI,
• RESTfulness: support for HTTP verbs PUT / DELETE, enforcement of the semantics of GET / POST (may be difficult to maintain backward-compatibility)

Mid-term goals

The mid-term goals are:

• possibility to add new base types (Array, HStore, Geometry, TSVector, etc.) that would use extensions from the SQL backend

• FROM clause in rql queries

• websockets

• defining attribute on relations and defining "virtual" relations or rules:

  class Contribution(EntityType):
      author = SubjectRelation('Person', cardinality='1*', inlined=True)
      book = SubjectRelation('Book', cardinality='1*', inlined=True)
      role = SubjectRelation('Role', cardinality='1*', inlined=True)
  
  preface_writer = VirtualRelation('C is Contribution, C author S, C book O, '
                                   'C role R, R name "preface writer"')
  

  And:

  Any P WHERE B is Book, P preface_writer B
  

  Will we need a materialized view in the database, a standard relation maintained by hooks, rewrite the RQL on-the-fly ? Time will tell.

• cards with logic (mustache js templates for example)

• coffeescript ? brython ? javascript ? prototype something with CubicDB + WebService that outputs json + user interface in full javascript

• package separately Cubic(Web)DB et CubicWeb ?

• think about the overall architecture (using WSGI, persistent sessions, etc.), and find solutions that fit a distributed architecture (look at paste.deploy, circus, etc.)

• clean up the javascript en web/data/*.js

• configurable metadata, managing the size of the entities table

• more SPARQL

• namespaces for the data models of the cubes

As already said on the mailing list, other developers and contributors are more than welcome to share their own goals in order to define a roadmap that best fits everyone's needs.

Logilab's next roadmap meeting will be held at the beginning of April 2013.

New functionalities

• Add a new dataimport store (SQLGenObjectStore). This store enables a fast import of data (entity creation, link creation) in CubicWeb, by directly flushing information in SQL. This may only be used with PostgreSQL, as it requires the 'COPY FROM' command.

API changes

• Orm: set_attributes and set_relations are unified (and deprecated) in favor of cw_set that works in all cases.

• db-api/configuration: all the external repository connection information is now in an URL (see #2521848), allowing to drop specific options of pyro nameserver host, group, etc and fix broken ZMQ source. Configuration related changes:

  • Dropped 'pyro-ns-host', 'pyro-instance-id', 'pyro-ns-group' from the client side configuration, in favor of 'repository-uri'. NO MIGRATION IS DONE, supposing there is no web-only configuration in the wild.
  • Stop discovering the connection method through repo_method class attribute of the configuration, varying according to the configuration class. This is a first step on the way to a simpler configuration handling.

  DB-API related changes:

  • Stop indicating the connection method using ConnectionProperties.
  • Drop _cnxtype attribute from Connection and cnxtype from Session. The former is replaced by a is_repo_in_memory property and the later is totaly useless.
  • Turn repo_connect into _repo_connect to mark it as a private function.
  • Deprecate in_memory_cnx which becomes useless, use _repo_connect instead if necessary.

• the "tcp://" uri scheme used for ZMQ communications (in a way reminiscent of Pyro) is now named "zmqpickle-tcp://", so as to make room for future zmq-based lightweight communications (without python objects pickling).

• Request.base_url gets a secure=True optional parameter that yields an https url if possible, allowing hook-generated content to send secure urls (e.g. when sending mail notifications)

• Dataimport ucsvreader gets a new boolean ignore_errors parameter.

Unintrusive API changes

• Drop of cubicweb.web.uicfg.AutoformSectionRelationTags.bw_tag_map, deprecated since 3.6.

User interface changes

• The RQL search bar has now some auto-completion support. It means relation types or entity types can be suggested while typing. It is an awesome improvement over the current behaviour !
• The action box associated with table views (from tableview.py) has been transformed into a nice-looking series of small tabs; it means that the possible actions are immediately visible and need not be discovered by clicking on an almost invisible icon on the upper right.
• The uicfg module has moved to web/views/ and ui configuration objects are now selectable. This will reduce the amount of subclassing and whole methods replacement usually needed to customize the ui behaviour in many cases.
• Remove changelog view, as neither cubicweb nor known cubes/applications were properly feeding related files.

Other changes

• 'pyrorql' sources will be automatically updated to use an URL to locate the source rather than configuration option. 'zmqrql' sources were broken before this change, so no upgrade is needed...
• Debugging filters for Hooks and Operations have been added.
• Some cubicweb-ctl commands used to show the output of msgcat and msgfmt; they don't anymore.

1. Questionnaire de description du Projet

2. Vidéo de présentation

Lien permettant de télécharger une vidéo décrivant le Projet et ses fonctionnalités, d’une durée maximale de 3 minutes

Ce n’est pas la qualité de la vidéo qui est jugée, mais le projet lui-même. La vidéo doit permettre de rendre compte des fonctionnalités du projet. Les candidats sont encouragés à réaliser une capture d’é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’accéder au Projet, ou au code informatique compilé et interprétable du Projet

Par exemple : URL permettant de consulter, ou, le cas échéant, de télécharger l’application, accompagnée, si nécessaire, d’instructions à cet effet. L’application devra être facile à installer et aisément démontrable sur sa plateforme de destination.

http://www.cubicweb.org

4. Supports de communication

Elément visuel de description

Lien vers un élément visuel décrivant et mettant en valeur le projet et ses fonctionnalités (capture d’écran, page d’accueil, schéma de description).

Logo du projet

Lien vers le logo du projet.

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)
• ...

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

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))