>From: "Mattheus, Henner" <Henner.Mattheus@xxxxxxxxxxxxxxxxx>
>Organization:
>Keywords: 200008141307.e7ED7VN20893
henner-
>i want to add and remove dataReferences to/from a displayImpl. they all have
>the same domain (time) but eventually different ranges (several currencies).
>i wonder if there isn't an easier way to achieve this goal, than allways
>
>a) remove all ScalarMaps and dataReferences
>b) add all the previously used Maps
>c) add eventually newly needed maps
>d) add all the previously used dataReferences
>e) add the new dataReferences.
>
>it would be great if somebody could show me an easier way,
I don't think there is an easier way except to create your own
framework that does all this for you.
Unidata has been prototyping a concept that does some of what you
want. We have created a DisplayMaster/Displayable framework where
the DisplayMaster is basically the controller for a VisAD display
to which Displayables are added/removed, etc. The Displayables
each have the set of ScalarMaps that they need as well as the
DataReferences and ConstantMaps and basically controls how data
will be displayed. An example is an abstract class called
ContourLines which has setable properties like Color, LineWidth,
ContourLevels and the RealType that is mapped to Display.IsoContour.
The ContourLines Displayable is added to a DisplayMaster. When
new Data is set in the ContourLines displayable, the RealType is
checked to see if it is different than the previous. The Displayable
maintains a list of ScalarMaps that it uses in a TreeMap. If
a new ScalarMap is needed (because the RealType has changed), then
the TreeMap is updated and a PropertyChangeEvent is fired. The
DisplayMaster listens for the changes and rebuilds the display
(steps a-e in your example). There are some things you can change
without rebuilding the display. In ContourLines, you can set the
Color which is done through ConstantMaps. In that case, you can
change the color and all that happens is that the DataReference is
removed and readded with the new set of ConstantMaps.
This whole framework is not without problems though. One of them
is that a ScalarMap may have a Control associated with it. When you
change the ScalarMap, you get a new Control and you have to account
for that. The current framework does not account for RemoteDisplays
either. We are currently reassessing the best way to deal with
Controls and may have to rethink the whole design. However, the basic
idea that the Displayable knows how to keep track of it's DataReference
is very powerful.
Don
*************************************************************
Don Murray UCAR Unidata Program
dmurray@xxxxxxxxxxxxxxxx P.O. Box 3000
(303) 497-8628 Boulder, CO 80307
*************************************************************
Unidata WWW Server http://www.unidata.ucar.edu/
McIDAS Demonstration Machine http://mcdemo.unidata.ucar.edu/
*************************************************************
