Recommended Property Tree Enhancements: Difference between revisions

Jump to navigation Jump to search
m
"refactoring": two ideas seem pretty much related and could be implemented generically enough to be usable for both scenarios (taken from ideas page)
m (adding reference to frame pointer suggestion)
m ("refactoring": two ideas seem pretty much related and could be implemented generically enough to be usable for both scenarios (taken from ideas page))
Line 114: Line 114:
== Additional Ideas ==
== Additional Ideas ==


* introducing the concept of base/frame pointers for property nodes as described in [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11307.html] would surely simplify PropertyList XML files tremendously and make them much more intuitive to work with.
* introducing the concept of "base/frame pointers" for property nodes (and possibly attributes) as described in [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg11307.html] would surely simplify PropertyList XML files tremendously and make them much more intuitive to work with (this is in fact conceptually pretty much identical to another suggestion, to provide basically the same facility for (non-relative, file system) paths and filenames provided in aircraft/PropertyList XML files, as posted in response[http://mail.flightgear.org/pipermail/flightgear-devel/2004-November/032299.html] to a request by C. Olson to enable aircraft to become more easily relocatable [http://mail.flightgear.org/pipermail/flightgear-devel/2004-November/032294.html] [http://mail.flightgear.org/pipermail/flightgear-devel/2004-November/032295.html]). This could for example be achieved by generalizing the current concept of aliases or by introducing a possibility to set file-specific (or possibly just global) variables in XML files that can later on be referenced and resolved in attributes or nodes in the XML file, i.e. along the lines of (the details might still need to be discussed, though):
<pre>
  <PropertyList>
    <!-- setting up some variables to be used in attributes or nodes -->
    <xml-variable name="ROOT_TREE"></xml-variable>
    <xml-variable name="FG_ROOT"></xml-variable>
 
    <!-- preferably, the underlying code would feature support for recursion to allow for use such as: -->
    <xml-variable name="SIM">ROOT_TREE/sim<xml-variable>
    <xml-variable name="FG_AIRCRAFT">FG_ROOT/Aircraft</xml-variable>
 
    <!-- making use of "base pointers" to directly refer to the proper location instead of using lots of nested relative path specs -->
    <aircraft-filename type="string">%FG_ROOT%/myAircraft/myAc-set.xml</aircraft-filename>
    <some-property type="string">%ROOT_TREE%/gui/
  </PropertyList>
</pre>
 
Implementation-wise, it would be possible to add support for this by either extending the current XMLVisitor code in simgear, or by sub-classing it, so that a static std::map<std::string,std::string> could be used to store variable/value pairs, and automatically parse each encountered attribute or node value for a corresponding variable identifier token that should normally not show up in common use scenarios (such as i.e. '%'). That way, all such occurrences could be automatically looked up in the std::map and resolved to their corresponding equivalents at runtime. So that users would then be able to easily refer "short hands" for well-defined locations (it might make sense to differentiate between local and global xml variables, the latter of which could automatically take effect for all parsed XML files, while the former would only use a lookup map for the root XML file or any files it references using the include directive).


[[Category:RFC]]
[[Category:RFC]]
2,561

edits

Navigation menu