By the way, I think dynamic loading is a good umbrella term for lazy loading, on demand loading, and any other variation that may come up.
On May 18, 12:21 am, FND <[email protected]> wrote: > So, now that we've outlined the issues, where does this leave us - what > could/should we start with to create a simple proof of concept? > > -- F. I've taken a stab at creating a basic load on demand setup and just pushed two plugins to my fork of tiddlyweb-plugins: * loadinitial: http://github.com/moveek/tiddlyweb-plugins/tree/8e7421acb8dc6a242dfec246e7d8e5410afd9d38/loadinitial * tiddlylinkfilter: http://github.com/moveek/tiddlyweb-plugins/tree/8e7421acb8dc6a242dfec246e7d8e5410afd9d38/tiddlylinkfilter To try this out, grab both plugins, copy the config from the tiddlywebconfig.py supplied with loadinitial, and optionally tweak the list of initial tiddlers. The list of initial tiddlers in the config file is just an mselect query expressed as a dictionary (more on this below and in the README). The tiddlylinkfilter plugin extends the filter syntax with a new select attribute that is used in specifying some of the intial tiddlers in the aforementioned dictionary. I should note loadinitial requires the presence of the mselect plugin. It should be possible to pretty much plug and play. Install the plugins, and next time you access a tiddlywiki via a recipe, only the tiddlers listed in the config dictionary should load, the rest will be retrieved on demand. This basically amounts to duplicating the example Chris linked earlier, but doing it on the serverside, and adding a simple mechanism for controlling the select filter from the TiddlyWeb config file. Actually there's one minor issue that needs fixing before you can plug and play. The loadinitial plugin makes use of a custom key in the config dictionary called 'initial_tiddlers'. On encountering this custom key, the try block in the read_config() function (in config.py) throws a KeyError that is currently unhandled. Simply adding it to the except clause solves this problem. Both plugins have detailed READMEs, but I'll put a little explanatory info here: Since the question of what tiddlers are essential at load time is a bit open ended, the idea was to allow control over this aspect from tiddlywebconfig.py. Among the candidates for initial load are: * the tiddler DefaultTiddlers * tiddlers tagged systemConfig, * StyleSheet and other overridden shadow tiddlers All of those can contribute to the initial state of a tiddlywiki. Arguably the most obvious one is DefaultTiddlers. The plugins aim to provide a logical default selection based on the tiddlers listed above, and provide an easy way to add or remove tiddlers as desired. loadinitial makes it possible to list the tiddlers intended for initial load as a dictionary in tiddlywebconfig.py. Example: 'initial_tiddlers': { 'in': ['DefaultTiddlers'], 'tag': ['systemConfig'], 'title': ['SiteTitle', 'SiteSubtitle'] } The plugin takes the dictionary and expands it into an mselect query. The code that converts the dictionary is quite flexible: any number of attributes supported by the select filter can be used in the dictionary, and each attribute can take a list of any number of values. For instance to preserve only tiddlyweb's serverside functionality, the 'tag':[systemConfig'] line could be replaced with 'bag':['system']. For the sake of illustration, the above dictionary is expanded into the following filter query: mselect=title:SiteTitle,title:SiteSubtitle,tag:systemConfig,in:DefaultTiddlers The custom select attribute 'in' is provided by the tiddlylinkfilter plugin. It takes the name of a tiddler (call it the condition tiddler) and selects the condition tiddler and all tiddlers referenced in the condition tiddler. If the condition tiddler links to 20 other tiddlers, then all 20 of those tiddlers plus the condition tiddler are selected. In the example above, the filter first creates a list of all the tiddlylinks in the body of DefaultTiddlers; the compiled list of tiddlers is then used for selection. The filter was specifically written to handle the DefaultTiddlers case as TiddlyWiki expects all tiddlers listed in DefaultTiddlers to be available on load. This kind of touches on the concept FND mentions in his thread summary about determining essential tiddlers recursively. It might be termed something like "deep select." Well that's about it. I'm running this setup right now and noting problems that come up. This is just experimental and of course doesn't solve any other issues like handling of searches, but it provides a pretty good way of further testing a load on demand setup. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWikiDev?hl=en -~----------~----~----~----~------~----~------~--~---
