2009/3/20 Mathias Fröhlich wrote:
> Ok.
> But from my point of view the property tree is also used as a reflection
> framework to reflect objects state into the models/scripting/whatever. From
> my
> point of view, the serialization of the objects into xml is just a special
> case of that reflection stuff. Given that, you might consequently want to
> reflect
> more complex types by the properties.
The aggregate types are all constructed as combinations of our simpler
types. I think what I would propose is we could add an API layer which
could read or write a node as an aggregate type, but internally it would map
these complex types to a parent node with several children. So our current
xml tools and property tree manipulation tools would all continue to work as
before, but an additional higher level function call would make the node and
it's children optionally appear as a more complicated aggregate type. For
instance, considure the following property tree entries:
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2201;
/engines/engine[0]/rpm-history-arr/value[0] = 2200;
.
.
.
/engines/engine[0]/rpm-history-arr/value[999] = 2198;
We could access this with a new convenience aggregate accessor (untested)
:-) The accessor functions would use some simple conventions to assemble
and return an aggregate structure based on the simpler property tree
represenation:
vector<double> rpm =
fgGetDoubleVector("/engines/engine[0]/rpm-history-arr");
vector<double> rps;
for ( unsigned int i = 0; i < x.size(); i++ ) {
rps[i] = rpm[i] / 60.0;
}
fgSetDoubleVector( rps );
In this case, fgGetDoubleVector() would traverse the
/engines/engine[0]/rpm-history-arr parent node and find any children called
"value". It would take their individual values and copy them into a
vector<double> and return that to the calling layer.
Similarly, fgSetDoubleVector() would traverse the provided vector<double>
and write each subsequent value as a child called "value[n]" underneath the
specifed node.
Because we haven't changed the property system, this same example could also
be written using the current API like this (untested pseudo code):
rpm_node = fgGetNode("/engines/engine[0]/rpm-history-arr");
rps_node = fgGetNode("/engines/engine[0]/rps-history-arr");
unsigned int size = rpm_node.num_children();
for ( unsigned int i = 0; i < size; i++ ) {
tmp = rpm_node.get_child(i).getDoubleValue();
rps_node.get_child(i).setDoubleValue( tmp / 60.0 );
}
Nothing in the core/underlying property system would need to change, we
could just add some additional convenience functions that would map more
complex structures back and forth to a traditional property tree
representation. It's nothing that individual functions couldn't already do
themselves, so I don't see a problem with adding some additional API calls
if this is a convenience that could be used throughout the application.
My only additional comment is that if this approach is objectionable due to
performance or space considerations, then perhaps the property tree is not
the best place to be storing this data in the first place.
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
