I tried to extend sax2db (leo.externals.sax2db) script to collect settings data from outline and then I have realized that it would not bring any benefit. I have made a function which would examine outline and collect all settings from it and store the result in db table. However, Leo currently supports several kinds of at-if nodes in settings tree. Presence of such nodes makes function that traverses tree and collects settings an impure one. Collecting settings by traversing tree can make list or dictionary of currently valid settings, but same outline can give different result if traversed again. That prevents us for making any benefit of cached settings.
One way to deal with this would be to give every setting row in database one extra column which would contain list of all at-if conditions from its parents in outline. Then after opening db file Leo would have to evaluate all conditions and if they are True for all ancestor nodes those settings would make to final list of valid settings. Though it can be done, I would ask how many users do use such nodes? How many of them use at-if variant with arbitrary code in body that calculates if condition is True or not? At-ifhost and at-ifplatform perhaps, might be considered as immutable constants between two launches of Leo. They would rarely change and even if they do change (changing the name of computer, for example) perhaps user would want to change this headlines anyway. In that case it would suffice to run sax2db once again on settings files after such change occur. Is it necessary to support such flexibility? Does anyone uses it and for what? Maybe it can be added to list of special cases like ifhost and ifplatform. If there were not support for at-if nodes with arbitrary code in body, sax2db could collect settings and cache them in a table. Leo could in a few lines of code have fully functional and properly filled g.app.config and c.config at the very beginning of execution. That could greatly simplify Leo init code. Once again it would make no difficulties for sax2db to support all at-if nodes exactly as Leo supports them now under one restriction: that code in body of at-if node gives always same result for one settings file. Under such restriction it would be reasonable to cache settings and use them from cache. Cache would be automatically updated when settings are edited by Leo. But if that restriction is left then there would be no easy way to guarantee validity of cached settings. Also it is worth noting that Leo already supports settings per machine so the functionality of at-ifhost can be achieved by using more setting documents. So even if we drop support for at-ifhost user can achieve same effect with extracting machine specific settings in separate document. Vitalije -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
