Damus et Capimus

Last week's instalment of the CDO integration tech preview series for the Kepler release explored model validation in repository models. This week, we take a look at customizing the Properties View.

Papyrus offers end users a powerful model-driven solution for customization of the Properties View. This enables a convenient UI for editing model elements tailored to what's important in a specific domain, such as SysML, MARTE, or whatever you can invent yourself. In the Juno release, the models that describe the Properties View are stored in the local workspace's metadata area. Now, we bring them into the repository to share and access from any workspace.

Have a look at the video after the break for a quick (less than 10 minutes) tour.

The models defining the customization of the Properties View comprise three main components:

• Context model, connecting the organizational structure of views, tabs, and sections to The definitions if the UI and data context that determine the elements to which they are applicable
• EMF Facet query models defining constraints that select which elements any particular tabs or sections apply to
• XWT files containing the XML definitions of the UI: the property editor widgets

The XWT content poses an interesting conundrum: the engine that parses these files and instantiates the UI at run-time has no knowledge of EMF models or EMF resources and uses URLs to access XML text and JAXP to parse it. Moreover, the UML property sheet definitions comprise a large number of XWT files. Dozens upon dozens. Trying to retrofit all of this infrastructure onto EMF models would be a large undertaking, rather pointless (because it already works), and wouldn't scale well. An initial naïve experiment in loading all of these files as EMF-based model resources performed horribly in a local repository on a MacBook Pro with SSD storage.

Happily, the Kepler release of CDO provides exactly what is needed for this situation: CDOTextResource. This is a new kind of resource node that effectively provides a URI for a CLOB (character large object storage in the database). So, Papyrus stores customization models in the repository in a raft of text resources in the same hierarchical "file" structure as in the workspace. The context models a loaded into plain XMI resources persisted in the CLOBs, and the XWT files are accessed directly by the UI engine via Java URLs with a custom stream handler (using EMF to get I/O streams on the CDO URIs).

The end result is efficient storage of model and non-model data in the repository.

Apart from all of this, maintaining these customization models in the repository requires some resilience in the Properties View and clean handling of the volatility of connections to the repository, which is different from the workspace that is assumed always to be "connected". Papyrus keeps track, in the workspace metadata, of the properties view context models that it knows about. When a repository connection is opened, any contexts that it contains are discovered and made available to the UI. When a repository connection is closed, contexts are removed from the UI. And, because the models are in a shared repository, other users can make changes to them. These changes are pushed into the UI of other connected Papyrus workbenches in real time.

Have a look at the video above for a taste, and then check out the latest code from the cdo_kepler branch in SVN to play with it, yourself! And see bug 402961 for all of the gritty details.