Blog entries by Sylvain Thenault [22]
  • Logilab will be in Toulouse métropole Open Data Barcamp tomorrow

    2013/10/08 by Sylvain Thenault

    Meet us tomorrow at the Toulouse's Cantine where several people from Logilab will be there for the open data barcamp organized by Toulouse Metropole.

    More infos on We'll probably talk abouthow CubicWeb manages to import large amounts of open-data to reuse.

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

  • 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 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 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 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 (, 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:


    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?

  • What's new in CubicWeb 3.14?

    2011/11/10 by Sylvain Thenault

    The development of CubicWeb 3.14 was rather long and included a lot of API changes detailed here. As usual backward compatibility is provided for public APIs.

    Please note this release depends on yams 0.34 (which is incompatible with prior cubicweb releases regarding instance re-creation).

    API changes

    • Entity.fetch_rql the restriction argument has been deprecated and should be replaced with a call to the new Entity.fetch_rqlst method, get the returned value (a rql Select node) and use the RQL syntax tree API to include the above-mentioned restrictions.

      Backward compat is kept with proper warning.

    • Entity.fetch_order and Entity.fetch_unrelated_order class methods have been replaced by Entity.cw_fetch_order and Entity.cw_fetch_unrelated_order with a different prototype:

      • instead of taking (attr, var) as two string argument, they now take (select, attr, var) where select is the rql syntax tree being constructed and var the variable node.
      • instead of returning some string to be inserted in the 'ORDERBY' clause, it has to modify the syntax tree

      Backward compat is kept with proper warning, except if:

      • custom order method returns something else the a variable name with or without the sorting order (e.g. cases where you sort on the value of a registered procedure as it was done in the tracker for instance). In such case, an error is logged telling that this sorting is ignored until API upgrade.
      • client code uses direct access to one of those methods on an entity (no code known to do that).
    • Entity._rest_attr_info class method has been renamed to Entity.cw_rest_attr_info

      No backward compat since this is a protected method an no code is known to use it outside cubicweb itself.

    • AnyEntity.linked_to has been removed as part of a refactoring of this functionality (link a entity to another one at creation step). It was replaced by a EntityFieldsForm.linked_to property.

      In the same refactoring, cubicweb.web.formfield.relvoc_linkedto, cubicweb.web.formfield.relvoc_init and cubicweb.web.formfield.relvoc_unrelated were removed and replaced by RelationField methods with the same names, that take a form as a parameter.

      No backward compatibility yet. It's still time to cry for it. Cubes known to be affected: tracker, vcsfile, vcreview.

    • CWPermission entity type and its associated require_permission relation type (abstract) and require_group relation definitions have been moved to a new localperms cube. Some functions from the cubicweb.schemas package as well as some views where moved too. This makes cubicweb itself smaller while you get all the local permissions stuff into a single and documented place.

      Backward compat is kept for existing instances, though you should have installed the localperms cubes. A proper error should be displayed when trying to migrate to 3.14 an instance the use CWPermission without the new cube installed. For new instances / test, you should add a dependancy on the new cube in cubes using this feature, along with a dependancy on cubicweb >= 3.14.

    • jQuery has been updated to 1.6.4 and jquery-tablesorter to 2.0.5. No backward compat issue known.

    • Table views refactoring : new RsetTableView and EntityTableView, as well as rewritten an enhanced version of PyValTableView on the same bases, with logic moved to some column renderers and a layout. Those should be well documented and deprecates former TableView, EntityAttributesTableView and CellView, which are however kept for backward compat, with some warnings that may not be very clear unfortunatly (you may see your own table view subclass name here, which doesn't make the problem that clear). Notice that _cw.view('table', rset, *kwargs) will be routed to the new RsetTableView or to the old TableView depending on given extra arguments. See #1986413.

    • display_name don't call .lower() anymore. This may leads to changes in your user interface. Different msgid for upper/lower cases version of entity type names, as this is the only proper way to handle this with some languages.

    • IEditControlAdapter has been deprecated in favor of EditController overloading, which was made easier by adding dedicated selectors called match_edited_type and match_form_id.

    • Pre 3.6 API backward compat has been dropped, though data migration compatibility has been kept. You may have to fix errors due to old API usage for your instance before to be able to run migration, but then you should be able to upgrade even a pre 3.6 database.

    • Deprecated cubicweb.web.views.iprogress in favor of new iprogress cube.

    • Deprecated cubicweb.web.views.flot in favor of new jqplot cube.

    Unintrusive API changes

    • Refactored properties forms (eg user preferences and site wide properties) as well as pagination components to ease overridding.

    • New cubicweb.web.uihelper module with high-level helpers for uicfg.

    • New anonymized_request decorator to temporary run stuff as an anonymous user, whatever the currently logged in user.

    • New 'verbatimattr' attribute view.

    • New facet and form widget for Integer used to store binary mask.

    • New js_href function to generated proper javascript href.

    • match_kwargs and match_form_params selectors both accept a new once_is_enough argument.

    • printable_value is now a method of request, and may be given dict of formatters to use.

    • [Rset]TableView allows to set None in 'headers', meaning the label should be fetched from the result set as done by default.

    • Field vocabulary computation on entity creation now takes __linkto information into accounet.

    • Started a cubicweb.pylintext pylint plugin to help pylint analyzing cubes: you should now use

      pylint --load-plugins=cubicweb.pylintext

      to analyse your cubicweb code.


    User interface changes

    • Datafeed source now present an history of the latest import's log, including global status and debug/info/warning/error messages issued during imports. Import logs older than a configurable amount of time are automatically deleted.
    • Breadcrumbs component is properly kept when creating an entity with '__linkto'.
    • users and groups management now really lead to that (i.e. includes groups management).
    • New 'jsonp' controller with 'jsonexport' and 'ejsonexport' views.


    • Added option 'resources-concat' to make javascript/css files concatenation optional, making JS debugging a lot easier when needed.

    As usual, the 3.14 also includes a bunch of other minor changes, and bug fixes, though this time an effort has been done so that every API changes / new API should be listed here. Please download and install CubicWeb 3.14 and report any problem on the tracker and/or the mailing-list!


  • What's new in CubicWeb 3.13?

    2011/07/21 by Sylvain Thenault

    CubicWeb 3.13 has been developed for a while and includes some cool stuff:

    • generate and handle Apache's modconcat compatible URLs, to minimize the number of HTTP requests necessary to retrieve JS and CSS files, along with a new cubicweb-ctl command to generate a static 'data' directory that can be served by a front-end instead of CubicWeb
    • major facet enhancements:
      • nicer layout and visual feedback when filtering is in-progress
      • new RQLPathFacet to easily express new filters that are more than one hop away from the filtered entities
      • a more flexibile API, usable in cases where it wasn't previously possible
    • some form handling refactorings and cleanups, notably introduction of a new method to process posted content, and updated documentation
    • support for new base types : BigInt, TZDateTime and TZTime (in 3.12 actually for those two)
    • write queries optimization, and several RQL fixes on complex queries (e.g. using HAVING, sub-queries...), as well as new support for CAST() function and REGEXP operator
    • datafeed source and default CubicWeb xml parsers:
      • refactored into smaller and overridable chunks
      • easier to configure
      • make it work

    As usual, the 3.13 also includes a bunch of other minor enhancements, refactorings and bug fixes. Please download and install CubicWeb 3.13 and report any problem on the tracker and/or the mailing-list!


  • What's new in CubicWeb 3.11?

    2011/02/18 by Sylvain Thenault

    Unlike recent major version of CubicWeb, the 3.11 doesn't come with many API changes or refactorings and introduces a fairly small set of new features. But those are important features!

    • 'pyrorql' sources mapping is now stored in the database instead of a python file in the instance's home. This eases the deployment and maintenance of distributed aplications.

    • A new 'datafeed' source was introduced, inspired by the soon to be deprecated datafeed cube. It needs polishing but sets the foundation for advanced semantic web applications that import content from others site using simple http request.

      A 'datafeed' source is associated to a parser that analyses the imported data and then creates/updates entities accordingly. There is currently a single parser in the core that imports CubicWeb-generated xml and needs to be configured with a mapping information that defines how relations are to be followed. It provides a viable alternative to 'pyrorql' sources. Other parsers to import RDF, RSS, etc should come soon.

      A new facet to filter entities based on the source they came from is now available.

    • The management interface for users, groups, sources and site preferences was simplified so it should be more intuitive to newbies (and others). Most items have been dropped from the user drop-down menu and the simpler views were made available through the '/manage' url.

    • The default 'index' / 'manage' view has been simplified to deprecate features that rely on external folder and card cubes. That's almost the only deprecation warning you'll get in upgrading to 3.11. Just this one won't hurt!

    • The old_calendar module has been dropped in favor of jQuery's fullcalendar powered views. That's a great news for applications using calendar features. Since it was added to the exising calendar module, you shouldn't have to change anything to get it working, unless you were using old_calendar in which case you may have to update a few things. This work was initiated by our mexican friends from Crealibre.

    As usual, the 3.11 also includes a bunch of other minor enhancements, refactorings and bug fixes. Please download and install CubicWeb 3.11 and report any problem to the mailing-list!


  • Building my photos web site with CubicWeb part V: let's make it even more user friendly

    2011/01/24 by Sylvain Thenault

    We'll now see how to benefit from features introduced in 3.9 and 3.10 releases of CubicWeb

    Step 1: tired of the default look?

    OK... Now our site has its most desired features. But... I would like to make it look somewhat like my website. It is not after all. Let's tackle this first!

    The first thing we can to is to change the logo. There are various way to achieve this. The easiest way is to put a logo.png file into the cube's data directory. As data files are looked at according to cubes order (CubicWeb resources coming last), that file will be selected instead of CubicWeb's one.


    As the location for static resources are cached, you'll have to restart your instance for this to be taken into account.

    Though there are some cases where you don't want to use a logo.png file. For instance if it's a JPEG file. You can still change the logo by defining in the cube's file:

    LOGO = data('logo.jpg')

    The uiprops machinery has been introduced in CubicWeb 3.9. It is used to define some static file resources, such as the logo, default Javascript / CSS files, as well as CSS properties (we'll see that later).


    This file is imported specifically by CubicWeb, with a predefined name space, containing for instance the data function, telling the file is somewhere in a cube or CubicWeb's data directory.

    One side effect of this is that it can't be imported as a regular python module.

    The nice thing is that in debug mode, change to a file are detected and then automatically reloaded.

    Now, as it's a photos web-site, I would like to have a photo of mine as background... After some trials I won't detail here, I've found a working recipe explained here. All I've to do is to override some stuff of the default CubicWeb user interface to apply it as explained.

    The first thing to to get the <img/> tag as first element after the <body> tag. If you know a way to avoid this by simply specifying the image in the CSS, tell me! The easiest way to do so is to override the HTMLPageHeader view, since that's the one that is directly called once the <body> has been written. How did I find this? By looking in the cubiweb.web.views.basetemplates module, since I know that global page layouts sits there. I could also have grep the "body" tag in cubicweb.web.views... Finding this was the hardest part. Now all I need is to customize it to write that img tag, as below:

    class HTMLPageHeader(basetemplates.HTMLPageHeader):
        # override this since it's the easier way to have our bg image
        # as the first element following <body>
        def call(self, **kwargs):
            self.w(u'<img id="bg-image" src="%sbackground.jpg" alt="background image"/>'
                   % self._cw.datadir_url)
            super(HTMLPageHeader, self).call(**kwargs)
    def registration_callback(vreg):
        vreg.register_all(globals().values(), __name__, (HTMLPageHeader))
        vreg.register_and_replace(HTMLPageHeader, basetemplates.HTMLPageHeader)

    As you may have guessed, my background image is in a background.jpg file in the cube's data directory, but there are still some things to explain to newcomers here:

    • The call method is there the main access point of the view. It's called by the view's render method. It is not the only access point for a view, but this will be detailed later.
    • Calling self.w writes something to the output stream. Except for binary views (which do not generate text), it must be passed an Unicode string.
    • The proper way to get a file in data directory is to use the datadir_url attribute of the incoming request (e.g. self._cw).

    I won't explain again the registration_callback stuff, you should understand it now! If not, go back to previous posts in the series :)

    Fine. Now all I've to do is to add a bit of CSS to get it to behave nicely (which is not the case at all for now). I'll put all this in a cubes.sytweb.css file, stored as usual in our data directory:

    /* fixed full screen background image
     * as explained on
     * syt update: set z-index=0 on the img instead of z-index=1 on div#page & co to
     * avoid pb with the user actions menu
    img#bg-image {
        position: fixed;
        top: 0;
        left: 0;
        width: 100%;
        height: 100%;
        z-index: 0;
    div#page, table#header, div#footer {
        background: transparent;
        position: relative;
    /* add some space around the logo
    img#logo {
        padding: 5px 15px 0px 15px;
    /* more dark font for metadata to have a chance to see them with the background
     *  image
    div.metadata {
        color: black;

    You can see here stuff explained in the cited page, with only a slight modification explained in the comments, plus some additional rules to make things somewhat cleaner:

    • a bit of padding around the logo
    • darker metadata which appears by default below the content (the white frame in the page)

    To get this CSS file used everywhere in the site, I have to modify the file introduced above:

    STYLESHEETS = sheet['STYLESHEETS'] + [data('cubes.sytweb.css')]


    sheet is another predefined variable containing values defined by already process file, notably the CubicWeb's one.

    Here we simply want our CSS in addition to CubicWeb's base CSS files, so we redefine the STYLESHEETS variable to existing CSS (accessed through the sheet variable) with our one added. I could also have done:


    But this is less interesting since we don't see the overriding mechanism...

    At this point, the site should start looking good, the background image being resized to fit the screen.

    The final touch: let's customize CubicWeb's CSS to get less orange... By simply adding

    contextualBoxTitleBg = incontextBoxTitleBg = '#AAAAAA'

    and reloading the page we've just seen, we know have a nice greyed box instead of the orange one:

    This is because CubicWeb's CSS include some variables which are expanded by values defined in uiprops file. In our case we controlled the properties of the CSS background property of boxes with CSS class contextualBoxTitleBg and incontextBoxTitleBg.

    Step 2: configuring boxes

    Boxes present to the user some ways to use the application. Let's first do a few user interface tweaks in our file:

    from cubicweb.selectors import none_rset
    from cubicweb.web.views import bookmark
    from import views as zone
    from cubes.tag import views as tag
    # change bookmarks box selector so it's only displayed on startup views
    bookmark.BookmarksBox.__select__ = bookmark.BookmarksBox.__select__ & none_rset()
    # move zone box to the left instead of in the context frame and tweak its order
    zone.ZoneBox.context = 'left'
    zone.ZoneBox.order = 100
    # move tags box to the left instead of in the context frame and tweak its order
    tag.TagsBox.context = 'left'
    tag.TagsBox.order = 102
    # hide similarity box, not interested
    tag.SimilarityBox.visible = False

    The idea is to move all boxes in the left column, so we get more space for the photos. Now, serious things: I want a box similar to the tags box but to handle the Person displayed_on File relation. We can do this simply by adding a AjaxEditRelationCtxComponent subclass to our views, as below:

    from logilab.common.decorators import monkeypatch
    from cubicweb import ValidationError
    from cubicweb.web import uicfg, component
    from cubicweb.web.views import basecontrollers
    # hide displayed_on relation using uicfg since it will be displayed by the box below
    uicfg.primaryview_section.tag_object_of(('*', 'displayed_on', '*'), 'hidden')
    class PersonBox(component.AjaxEditRelationCtxComponent):
        __regid__ = 'sytweb.displayed-on-box'
        # box position
        order = 101
        context = 'left'
        # define relation to be handled
        rtype = 'displayed_on'
        role = 'object'
        target_etype = 'Person'
        # messages
        added_msg = _('person has been added')
        removed_msg = _('person has been removed')
        # bind to js_* methods of the json controller
        fname_vocabulary = 'unrelated_persons'
        fname_validate = 'link_to_person'
        fname_remove = 'unlink_person'
    def js_unrelated_persons(self, eid):
        """return tag unrelated to an entity"""
        rql = "Any F + ' ' + S WHERE P surname S, P firstname F, X eid %(x)s, NOT P displayed_on X"
        return [name for (name,) in self._cw.execute(rql, {'x' : eid})]
    def js_link_to_person(self, eid, people):
        req = self._cw
        for name in people:
            name = name.strip().title()
            if not name:
                firstname, surname = name.split(None, 1)
                raise ValidationError(eid, {('displayed_on', 'object'): 'provide <first name> <surname>'})
            rset = req.execute('Person P WHERE '
                               'P firstname %(firstname)s, P surname %(surname)s',
            if rset:
                person = rset.get_entity(0, 0)
                person = req.create_entity('Person', firstname=firstname,
            req.execute('SET P displayed_on X WHERE '
                        'P eid %(p)s, X eid %(x)s, NOT P displayed_on X',
                        {'p': person.eid, 'x' : eid})
    def js_unlink_person(self, eid, personeid):
        self._cw.execute('DELETE P displayed_on X WHERE P eid %(p)s, X eid %(x)s',
                         {'p': personeid, 'x': eid})

    You basically subclass to configure with some class attributes. The fname_* attributes give the name of methods that should be defined on the json control to make the AJAX part of the widget work: one to get the vocabulary, one to add a relation and another to delete a relation. These methods must start by a js_ prefix and are added to the controller using the @monkeypatch decorator. In my case, the most complicated method is the one which adds a relation, since it tries to see if the person already exists, and else automatically create it, assuming the user entered "firstname surname".

    Let's see how it looks like on a file primary view:

    Great, it's now as easy for me to link my pictures to people than to tag them. Also, visitors get a consistent display of these two pieces of information.


    The ui component system has been refactored in CubicWeb 3.10, which also introduced the AjaxEditRelationCtxComponent class.

    Step 3: configuring facets

    The last feature we'll add today is facet configuration. If you access to the '/file' url, you'll see a set of 'facets' appearing in the left column. Facets provide an intuitive way to build a query incrementally, by proposing to the user various way to restrict the result set. For instance CubicWeb proposes a facet to restrict based on who created an entity; the tag cube proposes a facet to restrict based on tags; the zoe cube a facet to restrict based on geographical location, and so on. In that gist, I want to propose a facet to restrict based on the people displayed on the picture. To do so, there are various classes in the cubicweb.web.facet module which simply have to be configured using class attributes as we've done for the box. In our case, we'll define a subclass of RelationFacet.


    Since that's ui stuff, we'll continue to add code below to our file. Though we begin to have a lot of various code their, so it's may be a good time to split our views module into submodules of a view package. In our case of a simple application (glue) cube, we could start using for instance the layout below:

    views/   # uicfg configuration, facets
    views/     # header/footer/background stuff
    views/ # boxes, adapters
    views/      # index view, 404 view
    from cubicweb.web import facet
    class DisplayedOnFacet(facet.RelationFacet):
        __regid__ = 'displayed_on-facet'
        # relation to be displayed
        rtype = 'displayed_on'
        role = 'object'
        # view to use to display persons
        label_vid = 'combobox'

    Let's say we also want to filter according to the visibility attribute. This is even simpler as we just have to derive from the AttributeFacet class:

    class VisibilityFacet(facet.AttributeFacet):
        __regid__ = 'visibility-facet'
        rtype = 'visibility'

    Now if I search for some pictures on my site, I get the following facets available:


    By default a facet must be applyable to every entity in the result set and provide at leat two elements of vocabulary to be displayed (for instance you won't see the created_by facet if the same user has created all entities). This may explain why you don't see yours...


    We started to see the power behind the infrastructure provided by the framework, both on the pure ui (CSS, Javascript) side and on the Python side (high level generic classes for components, including boxes and facets). We now have, with a few lines of code, a full-featured web site with a personalized look.

    Of course we'll probably want more as time goes, but we can now concentrate on making good pictures, publishing albums and sharing them with friends...

  • CubicWeb sprint in Paris on january 19/20/21 2011

    2010/12/03 by Sylvain Thenault

    Almost everything is in the title: we'll hold a CubicWeb sprint in our Paris office after the first French Semantic Web conference, so on 19, 20 and 21 of january 2011.

    The main topic will be to enhance newcomers experience in installing and using CubicWeb.

    If you wish to come, you're welcome, that's a great way to meet us, learn the framework and share thoughts about it. Simply contact us so we can check there is still some room available.

    photo by Sebastian Mary under creative commons licence.

  • What's new in CubicWeb 3.10?

    2010/10/18 by Sylvain Thenault

    The 3.10 development started during August, with two important patches: one on the repository / entity API, another one on the boxes / content navigation components unification (more on this later). Then it somewhat came to a halt, as more work was done on other projects and to stabilize the 3.9 branch. We finally got back on it during September, adding several other major changes or enhancements.

    • Cleanup of the repository side entity API, i.e. the API you may use when writing hooks. Beside simple namespace cleanup (a few renamings), the API has been modified to move out attributes being edited from the read cache. So now:

      • entities do not inherit from dict anymore; access to the dict protocol on an entity will raise deprecation warnings
      • the attributes cache is now a cw_attr_cache dictionary on the entity
      • edited attributes are in a cw_edited attribute special object, which is only available in hooks for a modified entity (i.e. '[before|after]_[add|update]_entity', you should use the dict protocol on that object to get modified attributes or to modify what is edited (in 'before' hooks only, and this is now enforced). This deprecates the former edited_attributes attribute.
    • Unification of 'boxes' / 'contentnavigation' registries and base classes, into "contextual components" stored in the 'ctxcomponents' registry. This implied the introduction of "layout" objects which are appobjects responsible of displaying the components according to the context they are displayed in.

      This separation of content / layout and some css cleanups allows us to move former boxes and content components into each other's place in the user interface: for instance, go to your preferences pages and try to move the search box. You now have many more different locations available. Though one component may not go anywhere, so forthcoming releases should tweak this to avoid proposing dumb choices. But the hot stuff is there!

      Also, a cache has been set on the registry to avoid recomputing possible components for each context (place in the ui).

    • Upgraded jQuery and jQuery UI respectively to version 1.4.2 and 1.8. Removed jquery.autocomplete.js since jQuery UI provides its own autocomplete plugin. A cwautocomplete plugin was added in order to keep widgets as backward compatible as possible. If you used custom autocomplete feature, you should take a look at this guide.

    • The RelationFacet base class now automatically proposes to search for entities without the relation if this is allowed by the schema and if there are some in current results. Example: search for tickets which are not planned in a version.

    • Data sources have been modeled as CubicWeb entity type CWSource. The 'sources' file is still there but will now only contains definition of the system source, as well as default manager account login and password. This implied changes in instance initialization commands, introduction of a new 'add-source' command to cubicweb-ctl, as well as change in the repository startup. Also, on a multi-sources instance, we can now search using a facet on the cw_source relation (a new mandatory metadata relation on each entities) to filter according to the data source entities are coming from.

    • Although introduced during 3.9 releases, it's worth mentioning the new support for multi-columns unicity constraint through yams's __unique_together__ entity type attribute, allowing for unicity constraint enforced by the underlying database instead of CubicWeb hooks. This is limited and doesn't work in every configuration, but is a must have when running several distributed CubicWeb instance of the same application (hence database).

    Also as usual, the 3.10 includes a bunch of other minor enhancements, refactorings and bug fixes. Every introduced change should be backward compatible, except probably some minor ui details due to the css box simplification. That's it.

    So please download and install CubicWeb 3.10 and report us any problem on the mailing-list!


  • Summer CubicWeb/Narval Sprint - Final report

    2010/08/18 by Sylvain Thenault

    For that last sprint day, each team made some nice achievements:

    • Steph & Alain worked on the mv/cp actions implementation to makes them working properly and supporting globs. Last but not least, with a full set of tests.
    • Alex & Charles got back what we call apycot 'full' tests, eg running test with coverage enabled, checking that code coverage is greater than a given threshold, but also running pylint and checking that its global evaluation is at least 7 (configurable, of course).
    • Katia & Aurélien provided a sharp implementation of recipe checking, so that we know we don't launch a recipe badly constructed, as well as informing the user nicely from what errors his recipe suffer.
    • Julien managed to set up a recipe managing from Debian package construction to Debian repository publication, going through lintian on the way
    • Pierre-Yves helped other teams to solve the narval related bugs they encountered, and finished by writing a thread-safe implementation of apycot's writer so we can run several checker simultaneously.
    • Celso continued working on a proof of concept blue-theme cube, wondering how to make CubicWeb looks nicer and be easily customisable in future versions.
    • Sylvain helped there and there and integrated patches...

    So we finally didn't get up to the demo. But we now have everything to set it up, so I've a good hope that we will have a beta version of our brand new production chain up and running before the end of August!

    Thanks to everyone for all this good work, and for this time spent all together!

  • Summer CubicWeb/Narval Sprint - Day 1

    2010/08/10 by Sylvain Thenault

    We started this first day by several presentations by Sylvain about Logilab's current development process workflow, and compared it to what it should be after the sprint. Sylvain also introduced Narval.

    We then set up a dev environment on everyone's computer: a working forge with a local Narval agent that can be used for tests during the week.

    Regarding more concrete tasks:

    • Charles and Alexandre started writing some basic Narval actions such as move, to move a file from a place to another, and had to grasp narval's concepts on the way.
    • Pierre-Yves dug into the code to understand how exceptions are propagated in the Narval engine, his goal was to get better reports.
    • Stéphanie and Alain worked on a nice bot status view.
    • Katia, Aurélien studied the new mercurial cache solution for vcsfile
    • Julien started some piece of documentation.
    • Celso, our Mexican friend, discovered some new features of recent cubicweb releases and setup his environment to later work on Spanish translation, CSS, etc.
    • Sylvain came with a basically working narval implementation on top of cubicweb, and spent the day helping various people...

  • Summer CubicWeb/Narval Sprint

    2010/08/10 by Sylvain Thenault

    Although this week is normally the regular annual holidays here at Logilab, some of us will sprint in Paris exceptionally.


    We're starting this week with an exciting goal: integrating all our release process into our continuous integration suite (through the apycot cube). Including Debian repository management, pypi registration, etc...

    The hot stuff to achieve this is the third resurrection of Narval, the project Logilab was originaly based on, but this time it is built on top of CubicWeb framework. Narval will be used to rewrite some parts of apycot, in order to make it more flexible and powerful.

    It is not just a refactoring or a simple upgrade! We hope to automate common tasks, simplify maintenance, and thus enhance release quality, but also gain a lot of functionality in near future.

    Sprint roadmap

    • merge Apycotbot process manager into a new Narval incarnation, and rewrite it as Narval actions and recipes
    • improve vcsfile cube with a new cache system for mercurial
    • define Logilab's release process as new Narval recipes, triggered by actions such as adding release tag into the source repository

    More detailed stuff will come with the sprint reports that we'll try to issue each day.


    This sprint is taking place in Logilab's offices in Paris from Monday the 9th to the 13th of August 2010.

  • Building my photos web site with CubicWeb part IV: let's make it more user friendly

    2010/07/13 by Sylvain Thenault

    Step 0: updating code to CubicWeb 3.9 / cubicweb-file 1.9

    CubicWeb 3.9 brings several improvements that we'll want to use, and the 1.9 version of the file cube has a major change: the Image type has been dropped in favor of an IImage adapter that makes code globally much cleaner (although this is not directly visible here). So the first thing to do is to upgrade our cube to the 3.9 API. As CubicWeb releases are mostly backward compatible, this is not mandatory but it's easier to follow changes as they come than having a huge upgrade to do at some point. Also, this remove deprecation warnings which are a bit tedious...

    Since we only have very few lines of code, this step is pretty simple. Actually the main thing we have to do is to upgrade our schema, to remove occurrences of the Image type or replace them by the File type. Here is the (striped) diff:

     class comments(RelationDefinition):
         subject = 'Comment'
    -    object = ('File', 'Image')
    +    object = 'File'
         cardinality = '1*'
         composite = 'object'
     class tags(RelationDefinition):
         subject = 'Tag'
    -    object = ('File', 'Image')
    +    object = 'File'
     class displayed_on(RelationDefinition):
         subject = 'Person'
    -    object = 'Image'
    +    object = 'File'
     class situated_in(RelationDefinition):
    -    subject = 'Image'
    +    subject = 'File'
         object = 'Zone'
     class filed_under(RelationDefinition):
    -    subject = ('File', 'Image')
    +    subject = 'File'
         object = 'Folder'
     class visibility(RelationDefinition):
    -    subject = ('Folder', 'File', 'Image', 'Comment')
    +    subject = ('Folder', 'File', 'Comment')
         object = 'String'
         constraints = [StaticVocabularyConstraint(('public', 'authenticated',
                                                    'restricted', 'parent'))]
     class may_be_readen_by(RelationDefinition):
    -    subject = ('Folder', 'File', 'Image', 'Comment',)
    +    subject = ('Folder', 'File', 'Comment',)
         object = 'CWUser'
    -from cubes.file.schema import File, Image
    +from cubes.file.schema import File
     File.__permissions__ = VISIBILITY_PERMISSIONS
    -Image.__permissions__ = VISIBILITY_PERMISSIONS

    Now, let's set the dependency in the __pkginfo__ file. As 3.8 simplifies this file, we can merge __depends_cubes__ (as introduced in the first blog of this series) with __depends__ to get the following result:

    __depends__ = {'cubicweb': '>= 3.9.0',
                   'cubicweb-file': '>= 1.9.0',
                   'cubicweb-folder': None,
                   'cubicweb-person': None,
                   'cubicweb-zone': None,
                   'cubicweb-comment': None,
                   'cubicweb-tag': None,

    If your cube is packaged for debian, it's a good idea to update the debian/control file at the same time, so you won't forget it.

    That's it for the API update, CubicWeb and cubicweb-file will handle other stuff for us. Easy, no?

    We can now start some more fun stuff...

    Step 1: let's improve site's usability for our visitors

    The first thing I've noticed is that people to whom I send links to photos with some login/password authentication get lost, because they don't grasp they have to login by clicking on the 'authenticate' link. That's probably because they only get a 404 when trying to access an unauthorized folder, and the site doesn't make clear that 1. you're not authenticated, 2. you could get more content by authenticating yourself.

    So, to improve this situation, I decided that I should:

    • make a login box appears for anonymous, so they see at a first glance a place to put the login / password information I provided
    • customize the 404 page, proposing to login to anonymous.

    Here is the code, samples from my cube's file:

    from cubicweb.selectors import is_instance
    from cubicweb.web import box
    from cubicweb.web.views import basetemplates, error
    class FourOhFour(error.FourOhFour):
        __select__ = error.FourOhFour.__select__ & anonymous_user()
        def call(self):
            self.w(u"<h1>%s</h1>" % self._cw._('this resource does not exist'))
            self.w(u"<p>%s</p>" % self._cw._('have you tried to login?'))
    class LoginBox(box.BoxTemplate, basetemplates.LogFormView):
        """display a box containing links to all startup views"""
        __regid__ = 'sytweb.loginbox'
        __select__ = box.BoxTemplate.__select__ & anonymous_user()
        title = _('Authenticate yourself')
        order = 70
        def call(self, **kwargs):
            self.w(u'<div class="sideBoxTitle"><span>%s</span></div>' % self.title)
            self.w(u'<div class="sideBox"><div class="sideBoxBody">')

    The first class provides a new specific implementation of the default page you get on a 404 error, to display an explicit message for anonymous users.


    Thanks to the selection mechanism, it will be selected for anonymous users, since the additional anonymous_user() selector gives it a higher score than the default, and not for authenticated since this selector will return 0 otherwise (hence the object won't be selectable).

    The second class defines a simple box, that will be displayed by default with boxes in the left column, thanks to default box.BoxTemplate'selector. The HTML is written to match default CubicWeb boxes style. To get the actual login form, we inherit from the LogFormView view which provides a login_form method (handling some stuff under the cover for us, hence the multiple inheritance), that we simply have to call to get the form's HTML.

    login box / 404 screenshot

    The login box and the custom 404 page for an anonymous visitor (translated in french)

    Step 2: providing a custom index page

    Another thing we can easily do to improve the site is... A nicer index page (e.g. the first page you get when accessing the web site)! The default one is quite intimidating (that should change in a near future). I will provide a much simpler index page that simply list available folders (e.g. photo albums in that site).

    from cubicweb.web.views import startup
    class IndexView(startup.IndexView):
        def call(self, **kwargs):
            if self._cw.cnx.anonymous_connection:
                self.w(u'<h4>%s</h4>\n' % self._cw._('Public Albums'))
                self.w(u'<h4>%s</h4>\n' % self._cw._('Albums for %s') % self._cw.user.login)
            self._cw.vreg['views'].select('tree', self._cw).render(w=self.w)
    def registration_callback(vreg):
        vreg.register_all(globals().values(), __name__, (IndexView,))
        vreg.register_and_replace(IndexView, startup.IndexView)

    As you can see, we override the default index view found in cubicweb.web.views.startup, getting back nothing but its identifier and selector since we override the top level view's call method.


    In that case, we want our index view to replace the existing one. We implement the registration_callback function, in which we code a registeration of everything in the module but our IndexView, then we register it instead of the former index view.

    Also, we added a title that tries to make it more evident that the visitor is authenticated, or not. Hopefully people will get it now!

    default index page screenshot

    The default index page

    new index page screenshot

    Our simpler, less intimidating, index page (still translated in french)

    Step 3: more navigation improvements

    There are still a few problems I want to solve...

    • Images in a folder are displayed in a somewhat random order. I would like to have them ordered by file's name (which will usually, inside a given folder, also result ordering photo by their date and time)
    • When clicking a photo from an album view, you've to get back to the gallery view to go to the next photo. This is pretty annoying...
    • Also, when viewing an image, there is no clue about the folder to which this image belongs to.

    I will first try to explain the ordering problem. By default, when accessing related entities by using the ORM's API, you should get them ordered according to the target's class fetch_order. If we take a look at the file cube's schema, we can see:

    class File(AnyEntity):
        """customized class for File entities"""
        __regid__ = 'File'
        fetch_attrs, fetch_order = fetch_config(['data_name', 'title'])

    By default, fetch_config will return a fetch_order method that will order on the first attribute in the list. We could expect to get files ordered by their name. But we don't. What's up doc ?

    The problem is that files are related to folder using the filed_under relation. And that relation is ambiguous, eg it can lead to File entities, but also to Folder entities. In such a case, since both entity types don't share the attribute on which we want to sort, we'll get linked entities sorted on a common attribute (usually modification_date).

    To fix this, we have to help the ORM. We'll do this in the method from the ITree folder's adapter, used in the folder's primary view to display the folder's content. Here's the code that I've put in our cube's file, since it's more logical stuff than view stuff:

    from cubes.folder import entities as folder
    class FolderITreeAdapter(folder.FolderITreeAdapter):
        def different_type_children(self, entities=True):
            rql = self.entity.cw_related_rql(self.tree_relation,
                                             self.parent_role, ('File',))
            rset = self._cw.execute(rql, {'x': self.entity.eid})
            if entities:
                return list(rset.entities())
            return rset
    def registration_callback(vreg):
        vreg.register_and_replace(FolderITreeAdapter, folder.FolderITreeAdapter)

    As you can see, we simply inherit from the adapter defined in the folder cube, then we override the different_type_children method to give a clue to the ORM's cw_related_rql method, that will generate the rql to get entities related to the folder by the filed_under relation (the value of the tree_relation attribute). The clue is that we only want to consider the File target entity type. By doing this, we remove the ambiguity and get back a RQL query that correctly orders files by their data_name attribute.


    • Adapters have been introduced in CubicWeb 3.9 / cubicweb-folder 1.8.
    • As seen earlier, we want to replace the folder's ITree adapter by our implementation, hence the custom registration_callback method.

    Ouf. That one was tricky...

    Now the easier parts. Let's start by adding some links on the file's primary view to see the previous / next image in the same folder. CubicWeb provides a component that do exactly that. To make it appear, it has to be adaptable to the IPrevNext interface. Here is the related code sample, extracted from our cube's file:

    from cubicweb.selectors import is_instance
    from cubicweb.web.views import navigation
    class FileIPrevNextAdapter(navigation.IPrevNextAdapter):
        __select__ = is_instance('File')
        def previous_entity(self):
            rset = self._cw.execute('File F ORDERBY FDN DESC LIMIT 1 WHERE '
                                    'X filed_under FOLDER, F filed_under FOLDER, '
                                    'F data_name FDN, X data_name > FDN, X eid %(x)s',
                                    {'x': self.entity.eid})
            if rset:
                return rset.get_entity(0, 0)
        def next_entity(self):
            rset = self._cw.execute('File F ORDERBY FDN ASC LIMIT 1 WHERE '
                                    'X filed_under FOLDER, F filed_under FOLDER, '
                                    'F data_name FDN, X data_name < FDN, X eid %(x)s',
                                    {'x': self.entity.eid})
            if rset:
                return rset.get_entity(0, 0)

    The IPrevNext interface implemented by the adapter simply consist of the previous_entity / next_entity methods, that should respectively return the previous / next entity or None. We make an RQL query to get files in the same folder, ordered similarly (eg by their data_name attribute). We set ascendant/descendant ordering and a strict comparison with current file's name (the "X" variable representing the current file).


    • Former implements selector should be replaced by is_instance or adaptable selector with CubicWeb >= 3.9. In our case, is_instance is used to tell our adapter to get File entities.

    Notice that this query supposes we wont have two files of the same name in the same folder. Fixing this is out of the scope of this blog. And as I would like to have at some point a smarter, context sensitive previous/next entity, I'll probably never fix this query (though if I had to, I would probably choose to add a constraint in the schema so that we can't add two files of the same name in a folder).

    One more thing: by default, the component will be displayed below the content zone (the one with the white background). You can change this in the site's properties through the ui, but you can also change the default value in the code by modifying the context attribute of the component:

    navigation.NextPrevNavigationComponent.context = 'navcontentbottom'


    context may be one of 'navtop', 'navbottom', 'navcontenttop' or 'navcontentbottom'; the first two being outside the main content zone, the two others inside it.

    screenshot of the previous/next entity component

    The previous/next entity component, at the bottom of the main content zone.

    Now, the only remaining stuff in my todo list is to see the file's folder. I'll use the standard breadcrumb component to do so. Similarly as what we've seen before, this component is controlled by the IBreadCrumbs interface, so we'll have to provide a custom adapter for File entity, telling the a file's parent entity is its folder:

    from cubicweb.web.views import ibreadcrumbs
    class FileIBreadCrumbsAdapter(ibreadcrumbs.IBreadCrumbsAdapter):
        __select__ = is_instance('File')
        def parent_entity(self):
            if self.entity.filed_under:
                return self.entity.filed_under[0]

    In this case, we simply use the attribute notation provided by the ORM to get the folder in which the current file (e.g. self.entity) is located.


    The IBreadCrumbs interface is a breadcrumbs method, but the default IBreadCrumbsAdapter provides a default implementation for it that will look at the value returned by its parent_entity method. It also provides a default implementation for this method for entities adapting to the ITree interface, but as our File doesn't, we've to provide a custom adapter.

    screenshot of the breadcrumb component

    The breadcrumb component when on a file entity, now displaying parent folder.

    Step 4: preparing the release and migrating the instance

    Now that greatly enhanced our cube, it's time to release it and to upgrade production site. I'll probably detail that process later, but I currently simply transfer the new code to the server running the web site.

    However, there's some commands to get things done properly... First, as I've added some translatable string, I have to run:

    $ cubicweb-ctl i18ncube sytweb

    To update the cube's gettext catalogs (the '.po' files under the cube's i18n directory). Once the above command is executed, I'll then update translations.

    To see if everything is ok on my test instance, I do:

    $ cubicweb-ctl i18ninstance sytweb
    $ cubicweb-ctl start -D sytweb

    The first command compile i18n catalogs (e.g. generates '.mo' files) for my test instance. The second command starts it in debug mode, so I can open my browser and navigate through the web site to see if everything is ok...


    In the 'cubicweb-ctl i18ncube' command, sytweb refers to the cube, while in the two other, it refers to the instance (if you can't see the difference, reread CubicWeb's concept chapter !).

    Once I've checked it's ok, I simply have to bump the version number in the __pkginfo__ module to trigger a migration once I'll have updated the code on the production site. I can check the migration is also going fine, by first restoring a dump from the production site, then upgrading my test instance.

    To generate a dump from the production site:

    $ cubicweb-ctl db-dump sytweb
    pg_dump -Fc --username=syt --no-owner --file /home/syt/etc/cubicweb.d/sytweb/backup/tmpYIN0YI/system sytweb
    -> backup file /home/syt/etc/cubicweb.d/sytweb/backup/sytweb-2010-07-13_10-22-40.tar.gz

    I can now get back the dump file ('sytweb-2010-07-13_10-22-40.tar.gz') to my test machine (using scp for instance) to restore it and start migration:

    $ cubicweb-ctl db-restore sytweb sytweb-2010-07-13_10-22-40.tar.gz
    $ cubicweb-ctl upgrade sytweb

    You'll have to answer some questions, as we've seen in an earlier post.

    Now that everything is tested, I can transfer the new code to the production server, apt-get upgrade cubicweb 3.9 and its dependencies, and eventually upgrade the production instance.


    This is a somewhat long post that starts showing you the way CubicWeb provides a highly configurable user interface, as well as powerful and reusable components. And there are a lot of others like those!

    So see you next time for part V, where we'll probably want to do more ui stuff!

  • CubicWeb 3.9 released

    2010/07/12 by Sylvain Thenault

    CubicWeb 3.9.0 went out last week. We now have tested it in production and fixed the remaining bugs, which means it is now show time!

    What's new in CubicWeb 3.9?

    The 3.9 release development was started by a one week long sprint at the beginning of May. The two goals were first to make it easier to customize the look and feel of a CubicWeb application, and second to do a big cleanup of the javascript library. This led to the following major changes.

    • We introduced property sheets, which replace former external_resources file, as well as define some constants that will be used to 'compile' cubicweb and cubes' stylesheets.
    • We started a new, clean cubicweb.css stylesheet, that tries to keep up with the rhythm. This is still a work in progress, and by default the old css is still used, unless specified otherwise in the configuration file.
    • We set the bases for web functional testing using windmill. See test cases in cubicweb/web/test/windmill/ and python wrapper in cubicweb/web/test_windmill/ if you want to use this in your own cube.
    • We set the bases for javascript unit-testing using qunit. See test cases in cubicweb/web/test/jstests/ and python wrapper in cubicweb/web/test_jscript/ if you want to use this in your own cube.
    • We cleaned the javascript code: the generic stuff moved into the cw namespace, the ajax api is now much simpler thanks to more generic and powerful functions. As usual backward compatibility was kept, which means that your existing code will still run, but you will see tons of deprecation warnings in the firebug console.
    • We implemented a simple documentation extraction system for javascript. Just put ReST in javascript comments, and get all the power of sphinx for documenting your javascript code.

    But that's not all! There are also two major changes in 3.9.

    Architectural change: adapters

    The first major change is the introduction of adapters, also found in the Zope Component Architecture and documented in the GoF book. This will allow for better application design and easier code reuse. You can see several usage in the framework, for instance the "ITree" adapter in cubicweb.entities.adapters, the "IBreadCrumbs" adapter in cubicweb.web.views.ibreadcrumbs, or still the "ICalendarable" adapter in cubicweb.web.views.calendar.

    Important full search improvement

    The second major change will benefit directly to end users: we worked with our friends from SecondWeb to expose the ranking feature found in postgres full-text search. This clearly improves the user experience when doing full-text searches. Ranking may be finely tuned by setting different weights to entity types, entity types attributes, or even be dynamically computed per entity instance. Of course, all this is done in an adapter, see "IFTIndexableAdapter" in cubicweb/entities/

    Minor changes

    Other minor changes include:

    • support for wildcard text search for application using postgres >= 8.4 as backend. Try searching for 'cub*' on for instance.
    • inline edition of composite relation
    • nicer, clickable, schema image of the data model
    • enhanced support for the SQLserver database


  • Using RQL's HAVING clause to by-pass limitation of the WHERE clause

    2010/06/09 by Sylvain Thenault

    The HAVING clause, as in SQL, has been originally introduced to restrict a query according to value returned by an aggregat function, e.g.:

    Any X GROUPBY X WHERE X relation Y HAVING COUNT(Y) > 10

    It may however be used for something else...

    For instance, let's say you want to get people whose uppercased first name equals to another person uppercased first name. Since in the WHERE clause, we are limited to 3-expression (<subject> <relation> <object>), such thing can't be expressed (believe me or try it out). But this can be expressed using HAVING comparison expression:

    Person X WHERE X firstname XFN, Y firstname YFN HAVING X > Y, UPPER(XFN) = UPPER(YFN)

    Nice, no? This open some new possibilities. Another example:

    Person X WHERE X birthday XB HAVING YEAR(XB) = 2000

    Get it? That lets you use transformation functions not only in selection but for restriction as well, which was the major flaw in the RQL language.

    Notice that while we would like this to work without the HAVING clause, this can't be currently be done because it introduces an ambiguity in RQL's grammar that can't be handled by yapps, the parser's generator we're using.

  • Deactivating the 'reledit' feature

    2010/06/09 by Sylvain Thenault

    The 'reledit' feature is the one that makes attributes/relations editable in entity's primary view for authorized users (you know, the pen that appears when your mouse is over a field's value, clicking on it making a form to edit this field appears).

    This is a nice feature, but you may not want it. It can be easily deactivated everywhere it's used automatically in the site by using the code snippet below:

    from cubicweb.web.views import editforms
    class DeactivatedAutoClickAndEditFormView(editforms.AutoClickAndEditFormView):
        def should_edit_attribute(self, entity, rschema, form):
            return False
        def should_edit_relation(self, entity, rschema, role, rvid):
            return False
    def registration_callback(vreg):

  • Building my photos web site with CubicWeb part III: storing images on the file-system

    2010/05/20 by Sylvain Thenault

    Step 1: configuring the BytesFileSystem storage

    To avoid cluttering my database, and to ease file manipulation, I don't want them to be stored in the database. I want to be able create File/Image entities for some files on the server file system, where those file will be accessed to get entities data. To do so, I've to set a custom BytesFileSystemStorage storage for the File/Image 'data' attribute, which holds the actual file's content.

    Since the function to register a custom storage needs to have a repository instance as a first argument, we have to call it in a server startup hook. So I added it in cubes/sytweb/ :

    from os import makedirs
    from os.path import join, exists
    from cubicweb.server import hook
    from cubicweb.server.sources import storage
    class ServerStartupHook(hook.Hook):
        __regid__ = 'sytweb.serverstartup'
        events = ('server_startup', 'server_maintenance')
        def __call__(self):
            bfssdir = join(self.repo.config.appdatahome, 'bfss')
            if not exists(bfssdir):
                print 'created', bfssdir
            storage = storages.BytesFileSystemStorage(bfssdir)
            set_attribute_storage(self.repo, 'File', 'data', storage)
            set_attribute_storage(self.repo, 'Image', 'data', storage)


    • how we built the hook's registry identifier (_regid__): you can introduce 'namespaces' by using their python module like naming identifiers. This is especially important for hooks where you usually want a new custom hook, not overriding / specializing an existent one, but the concept may be used for any application objects
    • we catch two events here: "server_startup" and "server_maintenance". The first is called on regular repository startup (eg, as a server), the other for maintenance task such as shell or upgrade. In both cases, we need to have the storage set, else we'll be in trouble...
    • the path given to the storage is the place where a file added through the ui (or in the database before migration) will be located
    • be aware that by doing this, you can't write queries that will try to restrict on the File and the Image data attribute anymore. Thankfully we don't usually do that on a file's content or more generally on attributes for the Bytes type

    Now, if you've already added some photos through the web ui, you'll have to migrate existing data so that the file's content will be stored on the file-system instead of the database. There is a migration command to do so, let's run it in the cubicweb shell (in actual life, you'd have to put it in a migration script as we saw last time):

    $ cubicweb-ctl shell sytweb
     entering the migration python shell
     just type migration commands or arbitrary python code and type ENTER to execute it
     type "exit" or Ctrl-D to quit the shell and resume operation
     >>> storage_changed('File', 'data')
     >>> storage_changed('Image', 'data')

    That's it. Now, the files added through the web ui will have their content stored on the file-system, and you'll also be able to import files from the file-system as explained in the next part.

    Step 2: importing some data into the instance

    Hey, we're starting to have some nice features, let's give this new web site a try. For instance if I have a 'photos/201005WePyrenees' containing pictures for a particular event, I can import it to my web site by typing

    $ cubicweb-ctl fsimport -F sytweb photos/201005WePyrenees/
    ** importing directory /home/syt/photos/201005WePyrenees
      importing IMG_8314.JPG
      importing IMG_8274.JPG
      importing IMG_8286.JPG
      importing IMG_8308.JPG
      importing IMG_8304.JPG


    The -F option tell that folders should be mapped, hence my photos will be all under a Folder entity corresponding to the file-system folder.

    Let's take a look at the web ui:

    Nothing different, I can't see the new folder... But remember our security model! By default, files are only accessible to authenticated users, and I'm looking at the site as anonymous, e.g. not authenticated. If I login, I can now see:

    Yeah, it's there! You can also notice that I can see some entities as well as folders and images the anonymous users can't. It just works everywhere in the ui since it's handled at the repository level, thanks to our security model.

    Now if I click on the newly inserted folder, I can see

    Great! I get my pictures in the folder. I can now give a nicer name to this folder (provided I don't intend to import from it anymore, else already imported photos will be reimported), change permissions, title for some pictures, etc... Having good content is much more difficult than having a good web site ;)


    We started to see here an advanced feature of our repository: the ability to store some parts of our data-model into a custom storage, outside the database. There is currently only the BytesFileSystemStorage available, but you can expect to see more coming in a near future.

    Also, we can now start to feed our web-site with some nice pictures! The site isn't perfect (far from it actually) but it's usable, and we can start using it and improve it on the way. The Incremental Cubic Way :)

    So see you next time to start tweaking the user interface!

  • CubicWeb 3.8 released

    2010/04/28 by Sylvain Thenault

    CubicWeb 3.8.0 went out last week, but now we have tested it, produced a 3.8.1, it's show time!

    What's new in CubicWeb 3.8?

    One of the most important change is http server update to move from deadend twisted.web2 to twisted.web. With this change comes the possibility to configure the maximum size of POST request in the configuration file (was hard-coded to 100Mo before).

    Other changes include:

    • CubicWeb should now be installable through pip or easy_install. This is still experimental, and we don't use it that much so please, give us some feedback! Some cubes are now also "pipable" (comment, blog...), but more will come with new releases.
    • .execute() function lost its cache key argument. This is great news since it was a pain to explain and most cubicweb users didn't know how to handle it well (and I'm thre greatest beneficer since I won't have to explain over and over again)
    • nicer schema and workflow views
    • refactored web session handling, which should now be cleaner, clearer, hence less buggy...
    • nicer skeleton generation for new cubes, cleaner __pkginfo__ (you don't have to define both __depends__ / __depends_cubes__ or __recommends__ / __recommends_cubes__ in the general case, and other cleanups)


  • Building my photos web site with CubicWeb part II: security, testing and migration

    2010/04/13 by Sylvain Thenault

    This post will cover various topics:

    • configuring security
    • migrating an existing instance
    • writing some unit tests


    Here are the read permissions I want:

    • folders, files, images and comments should have one of the following visibility rules:
      • 'public', everyone can see it
      • 'authenticated', only authenticated users can see it
      • 'restricted', only a subset of authenticated users can see it
    • managers (e.g. me) can see everything
    • only authenticated users can see people
    • everyone can see classifier entities (tag and zone)

    Also, unless explicity specified, the visibility of an image should be the same as the visibility of its parent folder and the visibility of a comment should be the same as the one of the commented entity. If there is no parent entity, the default visibility is 'authenticated'.

    Regarding write permissions, that's much easier:

    • the anonymous user can't write
    • authenticated users can only add comment
    • managers will add the remaining stuff

    Now, let's implement that!

    Proper security in CubicWeb is done at the schema level, so you don't have to bother with it in the views, for the users will only see what they have access to.

    Step 1: adding permissions to the schema

    In the schema, you can grant access according to groups or RQL expressions (users get access if the expression return some results). To implements the read security defined above, groups are not enough, we'll need to use RQL expressions. Here is the idea:

    • add a visibility attribute on folder, image and comment, with a vocabulary ('public', 'authenticated', 'restricted', 'parent')
    • add a may_be_read_by relation that links folder, image or comment to users,
    • add hooks to propagate permission changes.

    So the first thing to do is to modify the of my cube to define these relations:

    from yams.constraints import StaticVocabularyConstraint
    class visibility(RelationDefinition):
        subject = ('Folder', 'File', 'Image', 'Comment')
        object = 'String'
        constraints = [StaticVocabularyConstraint(('public', 'authenticated',
                                                   'restricted', 'parent'))]
        default = 'parent'
        cardinality = '11' # required
    class may_be_read_by(RelationDefinition):
        subject = ('Folder', 'File', 'Image', 'Comment',)
        object = 'CWUser'

    We can note the following points:

    • we've added a new visibility attribute to folder, file, image and comment using a RelationDefinition
    • cardinality = '11' means this attribute is required. This is usually hidden under the required argument given to the String constructor, but we can rely on this here (same thing for StaticVocabularyConstraint, which is usually hidden by the vocabulary argument)
    • the 'parent' possible value will be used for visibility propagation

    Now, we should be able to define security rules in the schema, based on these new attribute and relation. Here is the code to add to

    from cubicweb.schema import ERQLExpression
        'read':   ('managers',
                   ERQLExpression('X visibility "public"'),
                   ERQLExpression('X visibility "authenticated", U in_group G, G name "users"'),
                   ERQLExpression('X may_be_read_by U')),
        'add':    ('managers',),
        'update': ('managers', 'owners',),
        'delete': ('managers', 'owners'),
            'read':   ('managers', 'users'),
            'add':    ('managers',),
            'update': ('managers', 'owners',),
            'delete': ('managers', 'owners'),
            'read':   ('managers', 'users', 'guests'),
            'add':    ('managers',),
            'update': ('managers', 'owners',),
            'delete': ('managers', 'owners'),
    from cubes.folder.schema import Folder
    from cubes.file.schema import File, Image
    from cubes.comment.schema import Comment
    from cubes.person.schema import Person
    from import Zone
    from cubes.tag.schema import Tag
    Folder.__permissions__ = VISIBILITY_PERMISSIONS
    File.__permissions__ = VISIBILITY_PERMISSIONS
    Image.__permissions__ = VISIBILITY_PERMISSIONS
    Comment.__permissions__ = VISIBILITY_PERMISSIONS.copy()
    Comment.__permissions__['add'] = ('managers', 'users',)
    Person.__permissions__ = AUTH_ONLY_PERMISSIONS
    Zone.__permissions__ = CLASSIFIERS_PERMISSIONS
    Tag.__permissions__ = CLASSIFIERS_PERMISSIONS

    What's important in there:

    • VISIBILITY_PERMISSIONS provides read access to an entity:
      • if user is in the 'managers' group,
      • or if visibility attribute's value is 'public',
      • or if visibility attribute's value is 'authenticated' and user (designed by the 'U' variable in the expression) is in the 'users' group (all authenticated users are expected to be in this group)
      • or if user is linked to the entity (the 'X' variable) through the may_be_read_by permission
    • we modify permissions of the entity types we use by importing them and modifying their __permissions__ attribute
    • notice the .copy(): we only want to modify 'add' permission for Comment, not for all entity types using VISIBILITY_PERMISSIONS!
    • remaning parts of the security model is done using regular groups:
      • 'users' is the group to which all authenticated users will belong
      • 'guests' is the group of anonymous users

    Step 2: security propagation in hooks

    To fullfill our requirements, we have to implement:

    Also, unless explicity specified, the visibility of an image should be the same as
    the visibility of its parent folder and the visibility of a comment should be the same as the
    one of the commented entity. If there is no parent entity, the default visibility is

    This kind of 'active' rule will be done using CubicWeb's hook system. Hooks are triggered on database event such as addition of new entity or relation.

    The tricky part of the requirement is in unless explicitly specified, notably because when the entity addition hook is executed, we don't know yet its 'parent' entity (eg folder of an image, image commented by a comment). To handle such things, CubicWeb provides Operation, which allow to schedule things to do at commit time.

    In our case we will:

    • on entity creation, schedule an operation that will set default visibility
    • when a "parent" relation is added, propagate parent's visibility unless the child already has a visibility set

    Here is the code in cube's

    from cubicweb.selectors import implements
    from cubicweb.server import hook
    class SetVisibilityOp(hook.Operation):
        def precommit_event(self):
            for eid in self.session.transaction_data.pop('pending_visibility'):
                entity = self.session.entity_from_eid(eid)
                if entity.visibility == 'parent':
    class SetVisibilityHook(hook.Hook):
        __regid__ = 'sytweb.setvisibility'
        __select__ = hook.Hook.__select__ & implements('Folder', 'File', 'Image', 'Comment')
        events = ('after_add_entity',)
        def __call__(self):
            hook.set_operation(self._cw, 'pending_visibility', self.entity.eid,
    class SetParentVisibilityHook(hook.Hook):
        __regid__ = 'sytweb.setparentvisibility'
        __select__ = hook.Hook.__select__ & hook.match_rtype('filed_under', 'comments')
        events = ('after_add_relation',)
        def __call__(self):
            parent = self._cw.entity_from_eid(self.eidto)
            child = self._cw.entity_from_eid(self.eidfrom)
            if child.visibility == 'parent':


    • hooks are application objects, hence have selectors that should match entity or relation type to which the hook applies. To match relation type, we use the hook specific match_rtype selector.
    • usage of set_operation: instead of adding an operation for each added entity, set_operation allows to create a single one and to store the eids of the entities to be processed in the session transaction data. This is a good pratice to avoid heavy operations manipulation cost when creating a lot of entities in the same transaction.
    • the precommit_event method of the operation will be called at transaction's commit time.
    • in a hook, self._cw is the repository session, not a web request as usually in views
    • according to hook's event, you have access to different member on the hook instance. Here:
      • self.entity is the newly added entity on 'after_add_entity' events
      • self.eidfrom / self.eidto are the eid of the subject / object entity on 'after_add_relation' events (you may also get the relation type using self.rtype)

    The 'parent' visibility value is used to tell "propagate using parent security" because we want that attribute to be required, so we can't use None value else we'll get an error before we get any chance to propagate...

    Now, we also want to propagate the may_be_read_by relation. Fortunately, CubicWeb provides some base hook classes for such things, so we only have to add the following code to

    # relations where the "parent" entity is the subject
    S_RELS = set()
    # relations where the "parent" entity is the object
    O_RELS = set(('filed_under', 'comments',))
    class AddEntitySecurityPropagationHook(hook.PropagateSubjectRelationHook):
        """propagate permissions when new entity are added"""
        __regid__ = 'sytweb.addentity_security_propagation'
        __select__ = (hook.PropagateSubjectRelationHook.__select__
                      & hook.match_rtype_sets(S_RELS, O_RELS))
        main_rtype = 'may_be_read_by'
        subject_relations = S_RELS
        object_relations = O_RELS
    class AddPermissionSecurityPropagationHook(hook.PropagateSubjectRelationAddHook):
        __regid__ = 'sytweb.addperm_security_propagation'
        __select__ = (hook.PropagateSubjectRelationAddHook.__select__
                      & hook.match_rtype('may_be_read_by',))
        subject_relations = S_RELS
        object_relations = O_RELS
    class DelPermissionSecurityPropagationHook(hook.PropagateSubjectRelationDelHook):
        __regid__ = 'sytweb.delperm_security_propagation'
        __select__ = (hook.PropagateSubjectRelationDelHook.__select__
                      & hook.match_rtype('may_be_read_by',))
        subject_relations = S_RELS
        object_relations = O_RELS
    • the AddEntitySecurityPropagationHook will propagate the relation when filed_under or comments relations are added
      • the S_RELS and O_RELS set as well as the match_rtype_sets selector are used here so that if my cube is used by another one, it'll be able to configure security propagation by simply adding relation to one of the two sets.
    • the two others will propagate permissions changes on parent entities to children entities

    Step 3: testing our security

    Security is tricky. Writing some tests for it is a very good idea. You should even write them first, as Test Driven Development recommends!

    Here is a small test case that'll check the basis of our security model, in test/

    from cubicweb.devtools.testlib import CubicWebTC
    from cubicweb import Binary
    class SecurityTC(CubicWebTC):
        def test_visibility_propagation(self):
            # create a user for later security checks
            toto = self.create_user('toto')
            # init some data using the default manager connection
            req = self.request()
            folder = req.create_entity('Folder',
            photo1 = req.create_entity('Image',
            photo1.clear_all_caches() # good practice, avoid request cache effects
            # visibility propagation
            self.assertEquals(photo1.visibility, 'restricted')
            # unless explicitly specified
            photo2 = req.create_entity('Image',
            self.assertEquals(photo2.visibility, 'public')
            # test security
            req = self.request()
            self.assertEquals(len(req.execute('Image X')), 1) # only the public one
            self.assertEquals(len(req.execute('Folder X')), 0) # restricted...
            # may_be_read_by propagation
            # test security with permissions
            req = self.request()
            self.assertEquals(len(req.execute('Image X')), 2) # now toto has access to photo2
            self.assertEquals(len(req.execute('Folder X')), 1) # and to restricted folder
    if __name__ == '__main__':
        from logilab.common.testlib import unittest_main

    It is not complete, but it shows most of the things you will want to do in tests: adding some content, creating users and connecting as them in the test, etc...

    To run it type:

    [syt@scorpius test]$ pytest
    ========================  ========================
    -> creating tables [....................]
    -> inserting default user and default groups.
    -> storing the schema in the database [....................]
    -> database for instance data initialized.
    Ran 1 test in 22.547s

    The first execution is taking time, since it creates a sqlite database for the test instance. The second one will be much quicker:

    [syt@scorpius test]$ pytest
    ========================  ========================
    Ran 1 test in 2.662s

    If you do some changes in your schema, you'll have to force regeneration of that database. You do that by removing the tmpdb* files before running the test:

    [syt@scorpius test]$ rm tmpdb*

    BTW, pytest is a very convenient utilities to control test execution, from the logilab-common package.

    Step 4: writing the migration script and migrating the instance

    Prior to those changes, Iv'e created an instance, fed it with some data, so I don't want to create a new one, but to migrate the existing one. Let's see how to do that.

    Migration commands should be put in the cube's migration directory, in a file named file:<X.Y.Z> ('Any' being there mostly for historical reason).

    Here I'll create a migration/ file containing the following instructions:


    Then I update the version number in cube's to 0.2.0. And that's it! Those instructions will:

    • update the instance's schema by adding our two new relations and update the underlying database tables accordingly (the two first instructions)
    • update schema's permissions definition (the later instruction)

    To migrate my instance I simply type:

    [syt@scorpius ~]$ cubicweb-ctl upgrade sytweb

    I will then be asked some questions to do the migration step by step. You should say YES when it asks if a backup of your database should be done, so you can get back to the initial state if anything goes wrong...


    This is a somewhat long post that I bet you will have to read at least twice ;) There is a hell lot of information hidden in there... But that should start to give you an idea of CubicWeb's power...

    See you next time for part III !

  • Building my photos web site with CubicWeb (Part I)

    2010/04/01 by Sylvain Thenault

    Desired features

    • photo gallery;
    • photo stored onto the fs and displayed through a web interface dynamically;
    • navigation through folder (album), tags, geographical zone, people on the picture... using facets;
    • advanced security (eg not everyone can see everything). More on this later.

    Let's go then

    Step 1: creating a new cube for my web site

    One note about my development environment: I wanted to use packaged version of CubicWeb and cubes while keeping my cube in my user directory, let's say ~src/cubes. It can be done by setting the following environment variables:


    The new cube, holding custom code for this web site, can now be created using:

    cubicweb-ctl newcube --directory=~/src/cubes sytweb

    Step 2: pick building blocks into existing cubes

    Almost everything I want to represent in my web-site is somewhat already modelized in existing cubes that I'll extend for my needs:

    • folder, containing Folder entity type, which will be used as both 'album' and a way to map file system folders. Entities are added to a given folder using the filed_under relation.
    • file, containing File and Image entity type, gallery view, and a file system import utility.
    • zone, containing the Zone entity type for hierarchical geographical zones. Entities (including sub-zones) are added to a given zone using the situated_in relation.
    • person, containing the Person entity type plus some basic views.
    • comment, providing a full commenting system allowing one to comment entity types supporting the comments relation by adding a Comment entity.
    • tag, providing a full tagging system as an easy and powerful way to classify entities supporting the tags relation by linking the to Tag entities. This will allow navigation into a large number of pictures.

    Ok, now I'll tell my cube requires all this by editing cubes/sytweb/

    __depends_cubes__ = {'file': '>= 1.2.0',
                         'folder': '>= 1.1.0',
                         'person': '>= 1.2.0',
                         'comment': '>= 1.2.0',
                         'tag': '>= 1.2.0',
                         'zone': None,
    __depends__ = {'cubicweb': '>= 3.5.10',
    for key,value in __depends_cubes__.items():
        __depends__['cubicweb-'+key] = value
    __use__ = tuple(__depends_cubes__)

    Notice that you can express minimal version of the cube that should be used, None meaning whatever version available.

    Step 3: glue everything together in my cube's schema

    from yams.buildobjs import RelationDefinition
    class comments(RelationDefinition):
        subject = 'Comment'
        object = ('File', 'Image')
        cardinality = '1*'
        composite = 'object'
    class tags(RelationDefinition):
        subject = 'Tag'
        object = ('File', 'Image')
    class filed_under(RelationDefinition):
        subject = ('File', 'Image')
        object = 'Folder'
    class situated_in(RelationDefinition):
        subject = 'Image'
        object = 'Zone'
    class displayed_on(RelationDefinition):
        subject = 'Person'
        object = 'Image'

    This schema:

    • allows to comment and tag File and Image entity types by adding the comments and tags relations. This should be all we have to do for this feature since the related cubes provide 'pluggable section' which are automatically displayed in the primary view of entity types supporting the relation.
    • adds a situated_in relation definition so that image entities can be geolocalized.
    • add a new relation displayed_on relation telling who can be seen on a picture.

    This schema will probably have to evolve as time goes (for security handling at least), but since the possibility to change and update the schema evolving is one of CubicWeb features (and goals), we won't worry and see that later when needed.

    Step 4: creating the instance

    Now that I have a schema, I want to create an instance of that new 'sytweb' cube, so I run:

    cubicweb-ctl create sytweb sytweb_instance

    hint: if you get an error while the database is initialized, you can avoid having to reanswer to questions by running

    cubicweb-ctl db-create sytweb_instance

    This will use your already configured instance and start directly from the database creation step, thus skipping questions asked by the 'create' command.

    Once the instance and database are fully initialized, run

    cubicweb-ctl start sytweb_instance

    to start the instance, check you can connect on it, etc...

    Next times

    We will customize the index page, see security configuration, use the Bytes FileSystem Storage... Lots of cool stuff remaining :)

    Next post : security, testing and migration

  • CubicWeb 3.6 is (almost) out!

    2010/02/10 by Sylvain Thenault

    And that's great news, after several months of development (things started moving in the beginning of august 2009...), it should be available on our Debian repositories and ftp site in the next few hours.

    So, we can say this release contains a (too) large set of improvements and refactorings. I'll talk about the most important ones here.

    Appobject/Entity classes namespace cleanup

    First of all, the namespace cleanup... 3.6 is a step towards cleaning the entity classes (hence more generally appobject), which are used for a lot of things, making it impossible to tell for sure what could be used or not as an attribute or relation name. We decided to declare identifiers starting with \_cw or cw\_ reserved for the core classes. A lot of methods have been deprecated to cleanup the base appobject class namespace. The remaining methods on entity classes will be removed in future version, by the introduction of an ORM for database related methods, and by the (most probable) introduction of ZCA adapters for other aspects. The most notable renaming are:

    • .req -> ._cw
    • .rset -> .cw_rset
    • .row -> .cw_row
    • .col -> .cw_col

    This is probably what you'll see first when upgrading to 3.6: a huge stack of deprecation warnings on your screen :)

    Another step towards a nice and powerful form system

    • cleaner reponsibilities separation between form, field and widget

    • fields and widgets are now responsible for handling POSTed values (the editcontroller was handling this, making things really unflexible). The editcontroller has been rewritten and now properly gets values from fields. Another benefit is that you can now easily have a widget handling multiple inputs (see the new datetime picker for instance, or the custom widget for Bookmark.path)

    • refactored automatic forms:

      • rewrite 'generic relations' as a field
      • inlined forms are now encapsulated into a field

      so you get much more control on these parts of automatic forms by using mechanism provided generally by fields

      • clearer form relations tags: removed autoform_is_inlined, more understandable autoform_field_section

    Hooks refactoring

    Hooks are now regular appobjects, with selectors (don't forget to reuse Hook.__select__, remember that !). They should simply implement __call__ with no argument (well, only self) and will get info previously passed as argument as instance attributes, according to the matching event.

    Test API cleanup

    EnvBasedTC, ControllerTC, WebTest, RepoBasedTC are all gone. Simply use CubicWebTC, with an unified API similar to what you use in cubicweb-ctl shell and in usual development.

    The Bytes File System Storage

    You can now specify a custom storage for attributes of entities stored in the system source. This mechanism is used to provide a way to store Bytes attributes (such as for instance) as files on the file-system instead of BLOBs in the database. You can configure which attributes should use this storage for your instance and then everything is transparent.

    Schema definition changes (yams 0.27)

    In your schema definition file:

    • "symetric" should be correctly spelled "symmetric" :)
    • "permissions" was renamed to "__permissions__"

    Also, permissions for relations are now supported per definition, not per type, at the cost of a visible impact when writing/reading the schema.

    Note about backward compatibility

    We worked hard to keep backward compatibility, but you shouldn't upgrade to 3.6 without checking that everything is fine... Check notably:

    • forms, if you're using custom forms by overriding internal methods
    • import for date functions from cubicweb.utils (they moved to

    And also

    CubicWeb 3.6 comes with a set of 37 cubes "3.6"-ready to avoid too much warnings!


  • CubicWeb documentation mini-sprint report

    2010/02/10 by Sylvain Thenault

    We held a one day sprint last week in our Paris office, trying to improve CubicWeb's documentation.

    There is a huge work to do on this, much more than we can do on a one day sprint, even with many people. But you have to begin with something :)

    So, after a quick meeting to define priorities:

    • Stéphanie, Charles and later Sandrine (from her US home-office), began to add some documentation and screenshots to cubes. They started with the following cubes: addressbook, person, basket, tag, folder, forgotpwd, forge, tracker, vcsfile, keyword, blog and comment.
    • Julien explored sphinx abilities to build the index and extract docstrings. He applied this to improve the documentation of selectors.
    • Adrien (ach) and Celso, our friend from Mexico, tackled the task to improve the tutorial from a beginner's point of view.
    • Arthur added some pieces of documentation found in our intranet, mailing-list...
    • Pyves worked on a cubicweb-ctl command to generate schema images (png) for cubes, to include them in the cube's documentation.
    • Adrien (adim) and I helped the various teams.

    Huum, I think I did not forgot anyone...

    If there is still a lot to do (we need more doc sprints, stay tuned), this is really a nice start! This site should soon be updated to include more valuable cubes description and online documentation extracted from the contributed doc.

  • CubicWeb 3.6 sprint report

    2009/12/14 by Sylvain Thenault

    Last week we held a cubicweb sprint in our new Paris office !

    We were a nice number of people: 7 from the Logilab's crew, including Sandrine, our US representative, Celso and Carlos from Mexico, plus some others guests and colleagues working on (cubicweb based of course) customer projects.

    The objective of the sprint was to kick out the 3.6 version of cubicweb, a big refactoring release started by Adrien and I a few months ago. Unfortunatly we had been preempted by some other projects and the cubicweb development branch was simply painfully following changes done in the stable branch.

    Also, we decided to start using mq as a basis for code review. The sprint was a nice opportunity to test and see if it was actually usable for both developer and code reviewer. But more on this latter :)

    The tasks to achieve to get this release out were:

    1. resurrect the default branch after 3 months of nasty bugs introduced by simply merging from the stable branch without any time to test
    2. update main cubes to the new test / uicfg / hooks / members api
    3. finish the editcontroller (which handle post of most web forms) refactoring
    4. finish the relation permissions change, including migration
    5. update the documentation
    6. test real applications

    Of course this was ambitious :) Among those point 0. and 1. and 3. took us much more time than I expected. The editcontroller work (2.) has not been finished yet, and we didn't find any time for the documentation (4.).

    Besides this, everyone (well, me at least ;) enjoyed its time while working hard all together in our new meeting room! The 3.6 version still needs a little work before being released, but the development branch is definitly back, with a great bunch of cubes ready. Among them : comment, tag, blog, keyword, tracker, forge, card, nosylist, etc...

    So many thanks to everyone, and particularly to our Mexican friends Carlos and Celso... Tequila! ;)

    By the way the good news is that we plan to do more sprints like this now that we've some room for it!