[wdmmg-dev] Separation of visual styles from data and code

[Rufus Pollock]

On 28 April 2011 16:30, Gregor Aisch <mail at driven-by-data.net> wrote:
> Just thought it would be a good idea to join the WDMMG dev list, since I'm
> currently working on a new visualization for OpenSpendings. So, hello to all
> :-)
> Just talked to Friedrich and Carsten about how to store and maintain visual
> properties like colours and icons in the future.
> By now the colours are defined somewhere inside the database and the flash
> bubble viz contains some hardcoded icons. In general, I find it a bad idea
> to store visualization specific properties like colours in the database.
> Colours, icons and the like are core parts of the visualization (and not the
> data). A different visualization might want to use different colours and
> will definitely need a different set of icons than the ones used in the
> bubble chart.

I'm generally +1. The only point to make is that we do have 'view'
objects in the DB and, as presentation objects, I'm not sure why they
can't have this sort of info -- it would obviously be wrong though for
this info to be on core 'Domain Model' stuff.

> So what we need is a clear separation of data, code and visual styles. The
> data defines the budget items, the visual style defines how the items will
> look like and the code renders the items in a certain way. Some visual
> properties like colours might be re-used across different visualizations,
> others must be defined each time we introduce a new visualization or
> classification. Of course we can use fallbacks like random colours or
> default icons to reduce the amount of work a bit. In case of hierarchical
> classifications inheritance of visual properties might also be a good idea.
> We will develop a proposal for the visual style format while working on the
> new bubble charts. I think a JSON dict is a good starting point.

+1 again. In essence this is exactly what I thought view objects were
storing (though it may make more sense just to have these in json
files on disk rather than in the mongo db ...

Rufus