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

Rufus Pollock rufus.pollock at okfn.org
Thu Apr 28 15:51:07 UTC 2011

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 ...


More information about the openspending-dev mailing list