replying to myself :-) - in xml, the slots frame present an hierarchical structure as <slot> <slot:key>options</slot:key> <slot:value type="frame"> <slot> <slot:key>Accounts</slot:key> <slot:value type="frame"> <slot> <slot:key>Use Trading Accounts</slot:key> <slot:value type="string">t</slot:value> </slot> </slot:value> </slot> </slot:value> </slot> - in sqlite, the key/value slots hold the full path to the slot like id obj_guid name slot_type 58 39fb62a42d731ddaa64ecd4daa764063 options 9 59 e51867d989899ba91314ef7c5c2e246b options/Budgeting 9 60 e51867d989899ba91314ef7c5c2e246b options/Accounts 9 61 7d781ad6895569f66447d74947e600be options/Accounts/Use Trading Accounts 4
With the sqlite type of representation, one could ponder the use of the KVP Frame object as the name includes the hierarchical relation. On Tue, Dec 16, 2014 at 8:36 PM, Sébastien de Menten <sdemen...@gmail.com> wrote: > > Hello, > > I was wondering why there was a need for a KvpFrame type when the key was > nevertheless holding the full path to the value, for example a Book may > have the slot: > > "options" : a frame holding > "options/Accounts" : a frame holding > "options/Accounts/Use Trading Accounts" : a boolean > > If the names where just > "options" : a frame holding > "Accounts" : a frame holding > "Use Trading Accounts" : a boolean > then "options/Accounts/Use Trading Accounts" would be an hierachical path > across several frames to end to a value. > > But as we have anyway > "options/Accounts/Use Trading Accounts" : a boolean > why do we need the frames "options" and "options/Accounts" as we already > have the path/to/key that gives an hierarchical structure to the keys ? > Is it due to an historical decision ? Is it still useful today ? > > kr > > sebastien > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel