20,741
edits
Howto:Work with the Property Tree API: Difference between revisions
Jump to navigation
Jump to search
m
Howto:Work with the Property Tree API (view source)
Revision as of 09:01, 25 January 2012
, 25 January 2012→Modeling an API on top of the property tree
m (add my forum posting here: http://flightgear.org/forums/viewtopic.php?f=30&t=15101&p=148567#p148567) |
|||
| Line 13: | Line 13: | ||
==== Modeling an API on top of the property tree ==== | ==== Modeling an API on top of the property tree ==== | ||
The property tree's purpose is to provide access to internal variables, i.e. by allowing people to inspect internal variables in a read-only fashion, but also in a writable fashion in many cases. | |||
The property tree's support for "publishing" internal variables, that can be read from and written to using an intuitive symbolic name within a tree hierarchy, also makes it possible to register so called "listeners" which invoke internal code routines ("callbacks) whenever certain properties are accessed. | The property tree's support for "publishing" internal variables, that can be read from and written to using an intuitive symbolic name within a tree hierarchy, also makes it possible to register so called "listeners" which invoke internal code routines ("callbacks) whenever certain properties are accessed (read or modified). | ||
This, in turn, makes it also possible to emulate a signal/slots mechanism on top of the property tree, i.e. by using "output properties" as signals, and "input properties" as "slots". | This, in turn, makes it also possible to emulate a signal/slots mechanism (think Qt) on top of the property tree, i.e. by using "output properties" as signals, and "input properties" as "slots". | ||
Routines that can be invoked this way include core C++ code, but also Nasal scripts. | Routines that can be invoked this way include core C++ code, but also Nasal scripts. | ||
More and more subsystems in FlightGear make use of this method to implement a subsystem-specific high level interface on top of the property tree. | More and more subsystems in FlightGear make use of this method to implement a subsystem-specific high level interface on top of the property tree. | ||
There are certain advantages by using the property tree like this, because all FlightGear subsystems can easily access those "APIs" - i.e. once a certain feature is implemented and provided using the property tree, the corresponding features becomes accessible everywhere, it would no longer matter if you wanted to access the feature internally, e.g. using the property tree browser, using an XML configuration file, a Nasal script, a networking protocol or even the telnet/props interface - simply because all of these methods have access to the property tree. In other words, once a feature is implemented like this, RPC also becomes possible automatically. | There are certain advantages by using the property tree like this, because all FlightGear subsystems can easily access those "APIs" - i.e. once a certain feature is implemented and provided using the property tree, the corresponding features becomes accessible everywhere, it would no longer matter if you wanted to access the feature internally, e.g. using the property tree browser, using an XML configuration file, a Nasal script, a networking protocol or even the telnet/props interface - simply because all of these methods have access to the property tree. In other words, once a feature is implemented like this, RPC also becomes possible automatically. | ||