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.
To continue reading this article register now