[RFC] Retrieving and/or storing hierarchical information - a design challenge

Folks,

I am seeking feedback from designers/developers on this design challenge.

Background

TiddlyWiki allows you to model complex hierarchies’ such as project tasks or a chart of accounts. We can then make use of recursive macros or filters including the powerful Kin operator to “summarise” or evaluate information in the whole hierarchy or selected branches of that hierarchy. Other relevant operators and filter run prefixes are map and reduce.

This is sometimes referred to as “rolling up”.

I raise this design challenge for those who have worked with hierarchical data.

Since Information obtained by this approach is dependant on all relevant nodes in the hierarchy, such that if “one node was to change” then we need to “roll up” the hierarchy again, to get a current value (a total for example). This means as a rule we need to continuously “evaluate” the whole hierarchy.

  • We could use a button and set some fields to the values our rollup determines, for each branch of our hierarchy and the grand total, but the moment we do this is it potentially out of date.
  • As a result the more complex and larger a hierarchy the more we need to re-evaluate the values. Including when viewing a “node” in the hierarchy, if not the “leaves”

In some ways TiddlyWiki has already solved this problem for its own innerworkings as it renders the DOM tree only when a change occurs, and applies it only to the nodes it is displaying.

Question:
Can anyone see a way to leverage TiddlyWikis core facilities to more efficiently handle such “rollups”, handle hierarchies and trigger a refresh only when needed?

  • For example could we set an “event monitor” on all members of a hierarchy and use that to trigger a re-evaluation if a node is edited, otherwise use the previous evaluation?
  • Such evaluated values live between the temporary (in memory) values and those committed to storage in a tiddler or field. Have we any tools to facilitate such circumstances?
  • It would be great if the last “rollup” can be automatically committed to storage, but refresh if there is a change. Ideally as efficiently as TiddlyWiki does.
1 Like

Bump, in case we have some coding genius is interested using the new 5.3.x features

As I did describe at: Alternative to tags - #10 by pmario it’s the creation of DOM event-handlers that are slow and not the TW internal handling of the hierarchical structure.

So the way to go should be to reduce the number of DOM elements, that need to be drawn and completely remove the event-handlers if possible