CubicWeb is not an easy framework to get to know. It does not fit cleanly into the pattern of the other Python Web frameworks in this roundup. In fact, CubicWeb calls itself not a Web framework, but a semantic Web framework. Application construction in CubicWeb is data-driven, but CubicWeb is not merely a database Web-client construction set. It's more.
CubicWeb is awash in its own nomenclature. And the core CubicWeb term, and concept, is "cube." Roughly speaking, a cube is a minimal Web application -- a software component composed of a data model, the logic needed to manipulate that data, and the view code required to display the data. While a CubicWeb application could be built from a single cube, more often it is built by lashing together multiple cubes. This is easily done thanks to another core principle: reusability. In CubicWeb, cubes are designed to be combined with the same ease that an engineer snaps together electronic components to make a circuit.
CubicWeb's notion of a data source includes more than the RDBMS. Behind most every CubicWeb application is a "repository," a gathering of persistent data sources that can include relational databases, LDAP servers, XML streams, Google App Engine's data store, and others. The repository framework completely insulates the application from the details of the constituent data sources. A persistent data object in a CubicWeb application may consist of pieces drawn from multiple, disparate data sources, and the application is unaware of that fact.
One is tempted to categorize CubicWeb as a Web framework crafted to build database front-end Web applications. In a sense, that is true: The data model drives a CubicWeb application. And the data schema is the first thing you build when you create a CubicWeb app -- or, more specifically, when you create a new cube. But CubicWeb builds more than database management Web applications. It builds information management Web applications.
CubicWeb: Yams and RQL
You define CubicWeb data objects, called "entities," using an entity-relationship architecture derived from a Python library called Yams (Yet Another Magic Schema). Relationships between entity types are established via a triplet of objects. Two of the three define the pair of entities participating in the relationship, while the third defines the relation itself. These relation tuples, taken together, are the application's data model schema, in the same way that DDL (Data Definition Language) defines the schema of tables in an RDBMS.
And whereas you query and manipulate data in an RDBMS using SQL, you query and manipulate entities in a CubicWeb repository using RQL (Relation Query Language), a semantic query language similar to SPARQL, the recursively named query language for RDF (Resource Description Framework) data. The repository component of the CubicWeb framework provides a database API -- designed along the lines of the Python Standard Database API specification -- that traffics in RQL rather than SQL. In fact, coding against the CubicWeb repository looks a lot like coding against an ordinary RDBMS. Once your application has established a connection to the repository (whether an RDBMS or something else), it can assemble an RQL query and call a function to execute that query on the repository (translating RQL into SQL, for instance, behind the scenes). The function returns the response in a result set object, through which your application can iterate to retrieve the returned entities.
There are a variety of ways to install CubicWeb, and you should work through that section of the online documentation carefully, because the framework relies on numerous other libraries, including Twisted, Pyro, and Lxml. Though not recommended, I was able to install CubicWeb on Ubuntu Linux using the Python
easy_install tool. (I had tried, and failed, to install by downloading the source.)
CubicWeb comes with a general-purpose command-line management tool called
cubicweb-ctl. Documentation refers to it as "the Swiss [Army] knife to manage CubicWeb instances." Not only does
cubicweb-ctl provide application management, but it also provides viewing and some editing of installed cubes and database instances.
CubicWeb: Runtime views
Ultimately, of course, you end up building a Web interface so that users can interact with your application. In CubicWeb, you don't build Web pages for the Web interface -- you build views. CubicWeb uses a multidispatch system that lets you define a set of views from which the user's view will be selected at runtime. That choice is based on the current context, which is a blend of the data to be displayed, the HTTP request, the current user's permissions, and other factors. The result is a highly adaptable and componentized view system.
CubicWeb's online documentation is presented as an online book. It includes two tutorials. One walks you through the installation of a blog application. The other demonstrates how to create a photo album application by gluing together existing cubes. The site also provides a tutorial illustrating the use of the Windmill testing framework.
CubicWeb is compatible with any 2.x version of Python later than 2.5. While it can be run in development mode using its own built-in Web server, which is based on the Twisted Web server, a production system should be run on the Apache Web server. CubicWeb engineers are working on improving the framework's WSGI support, so that by the time you read this, CubicWeb may be usable with any WSGI-compliant server.
CubicWeb is not your typical Web framework, and it requires more than the usual study to comprehend and appreciate. The tutorials are good, and they go a long way to illustrate CubicWeb's concepts in action. More tutorials would certainly be welcome -- as would a collection of how-to Web pages. But CubicWeb is designed for the long haul. Because you can assemble new applications simply by connecting existing cubes together, application creation accelerates as you build a collection of reusable cubes.