Global Style Handling: Config, Server, View, and Window

Old and new strategy

Traditionally display styles were related to ACEDB methods (NB this terminology may be wrong...) and these styles included some state information. Given that the same style could be applied to more than one column this required styles to be copied before use and this resulted in some quite complex code and data structures.

To resolve this the state information has been move into the ContainerFeatureset (bump mode) and replaced by server options (deferred and loaded) resulting in styles as static data that simply describe how to display features. This also allows styles to be referred to directly instead of being looked up everytime access was needed, which will be a lot more efficient.

Styles are merged into a global (to the view) table as they are supplied by servers - the ZMap server model is one where each server supplies styles for its features although in practice ZMap supplies these to the server and then retrieves them. Each display window (pane) is given the global list of styles and traditionally maintained a read-only (original) and volatile copy (with state information). Various functions were written to juggle all this information and distribute it.

More recently this code has been changed to allow each feature to refer to its style directly (and also the containing featureset and ContainerFeatureset and to have on copy of this information per view which is referred to directly without copying, which means that it will not be necessary to maintain updater functions.

Handling Styles in Server modules

Each server ultimately returns a feature context containing distinct featuresets. Each featureset and each feature has a pointer to the relevant style of which there can only be one (but note that some styles may have sub-features styles that are referred to directly.

To be able to do this a server must provide or be given a style table with the relevant styles and the server protocol (which was based on ACEDB) is used to pass a file to pipe servers which then read this, pass the data to ZMap which then passes it back to the server for use when reading features.

Handling Styles in View modules

When handling the server protocol ZMap will be given a style table by the server and this will be merged into any existing data. A few hard coded styles are defined and these are passed to all servers. Merging operates so as to not overwrite existing styles, but each server provides nested style defintions that can inherit data from within its own set of styles. Merging allows previously undefined attributes to be defined by a subesequent server call but existing data is not modified.

Current practice (October 2010) is that all styles are defined in a file and passed to all servers, in which case servers such as ACEDB should use the supplied data and not it's own. Individual featuresets are requsted from pipe servers and each one returns a newly generated copy of the same table of styles, which is then merged into an identical table by ZMapView. This table is then passed back to the server which points features into the appropriate style structure.

Handling Styles in Window modules

Window modules take multiple copies of style data - two copies held by ZMapWindow and each Canvas ContainerFeatureset also has a copy of the styles it needs (for optimised lookup). All this data needs to be updated as new featuresets are retrieved.

Features can refer to styles directly but some styles such as 3F translation have to be looked up in the global table when required, as there may not be a permanent feature to refer to this.

Suggested improvements