CubicWeb roadmap meeting on January 8th, 2015
The Logilab team holds a roadmap meeting every two months to plan its CubicWeb development effort. The previous roadmap meeting was in November 2014.
Here is the report about the January 8th, 2015 meeting.
Christophe de Vienne (Unlish) and Aurélien Campéas (self-employed) joined us to express their concerns and discuss the future of CubicWeb.
This version is stable but old and maintained (current is 3.18.7).
This version is stable and maintained (current is 3.19.8).
This version has been released a few days ago. It has not been deployed on production systems yet.
Its main features are:
virtual relations: a new ComputedRelation class can be used in schema.py; its rule attribute is an RQL snippet that defines the new relation.
computed attributes: an attribute can now be defined with a formula argument (also an RQL snippet); it will be read-only, and updated automatically.
Both of these features are described in CWEP-002, and the updated "Data model" chapter of the CubicWeb book.
cubicweb-ctl plugins can use the cubicweb.utils.admincnx function to get a Connection object from an instance name.
new 'tornado' wsgi backend
rich text fields can be formatted as markdown
the edit controller detects concurrent editions, and raises a ValidationError if an entity was modified between form generation and submission
cubicweb can use a postgresql "schema" (namespace) for its tables
cubicweb-ctl configure can be used to set values of the admin user credentials in the sources configuration file
For details read list of tickets for CubicWeb 3.20.0.
We would have loved to integrate the pyramid cube in this release, but the debian packaging effort needed by the pyramid stack is quite big and is acceptable if we target jessie only (at decent price).
For now, the roadmap for 3.21 is still the complete removal of the dbapi, the merging of Connection and ClientConnection.
Integrate the pyramid cube to provide the pyramid command if the pyramid framework can be imported.
Integration of CWEP-003 (FROM clause for RQL) and CWEP-004 (cubes as standard python packages) is being discussed.
We expect to accelerate development of CubicWeb 4, which exact roadmap is still to be discussed, but we may already want:
- be pyramid-based (remove twisted, auth management, etc.),
- do not have anything left of old dbapi and ClientConnection,
- integrate squareui as main (and only) web-ui "template" or remove web generation (almost) completely from cubicweb-core and provide it only through the cube system.
- apycot 3.2.0
- cubicweb-brainomics 0.11.5
- cubicweb-card 0.5.4
- cubicweb-container 2.7.0
- cubicweb-elections 0.2.0, 0.2.1
- cubicweb-fastimport 0.2.1
- cubicweb-forgotpwd 0.6.1
- cubicweb-inlinedit 1.2.1
- cubicweb-mercurial-server 0.6.0
- cubicweb-nazcaui 0.3.1
- cubicweb-registration 0.6.0
- cubicweb-signedrequest 0.1.3
- cubicweb-subprocess 0.2.1
- cubicweb-timeseries 1.4.0
- cubicweb-timesheet 0.12.0
- cubicweb-trackervcs 1.2.0
- cubicweb-transactionlog 0.3.0
- cubicweb-treeview 0.1.1
- cubicweb-vcreview 2.0.0
- cubicweb-vcsfile 1.17.0, 2.0.0
- cubicweb-vcwiki 0.3.0
- cubicweb-worker 3.1.0
- cubicweb-wsme 0.1.1, 0.1.2, 0.1.3, 0.1.4, 0.1.5
- narval 4.1.1
- cwclientlib 0.2.1
- pyramid-cubicweb 0.1.2, 0.1.3
- rqlquery 0.2.0, 0.2.1
Next roadmap meeting will be held at the beginning of march 2015 at Logilab. Interested parties are invited to get in touch.
Refactoring the documentation
Christophe de Vienne suggested to completely revamp the documentation and intends to lead this effort.
Aurélien Campéas asks if Logilab would be willing to share its training material under a free license to help interested parties organize and sell trainings.
Towards making squareui the default rendering engine for cubicweb
We are expecting to be able to use squareui/bootstrap as "rendering engine" for our forge applications (like https://www.cubicweb.org and http://www.logilab.org) as soon as possible. However to achieve to goal, there are still too many "visual bugs", some of which may require a discussion.
- put the ctxtoolbar component in the <nav> div
- each box component should have an icon (what API for this?)
- we cannot easily make the left column of the main template responsive-aware (requires to change the html flow), so it's probably best to take inspiration from things like http://wrapbootstrap.com/preview/WB0N89JMK
- facet boxes are a mess, there is no simple solution to have a "smart layout"
- AppObjects should not be loaded by default
- Have a look at Alembic the migration tool for SQLAlchemy and take inspiration from there.