@Scott_Sauyet I am not exactly sure why but on this subject an example that comes to mind is $:/temp/volatile/ mentioned in RefreshThrottling or using a namespace. This thread has helped me clarify in my mind a little more on handling different namespaces.
In brief, a startup action can take steps to store whatever it wants from whatever information is available such as the $:/info tiddlers, and store it how it wants.
- Arguably if all information is stored on the URI that simply saving this should be enough to craft a link to reload with the same URI, you called this “Home”
- Storing something the startup actions determines in tiddlers and fields of tiddlers, be they temporary, volatile or permanent (if save is possible) the designer can decide what to call them and use a namespace or naming convention.
Namespaces
We can simply adopt a namespace for whatever we want either inside the system name space $:/new or outside #:/new the detail is of course how different parts of tiddlywiki then handle the tiddlers with a given namespace. Areas we may want to alter are;
- Do they appear on standard searches, use
$:/to stop this already - Do they appear in common lists eg: recent/open
- How are they displayed in the story - now we have the cascades to handle this aspect for view, body, title etc…
In relation to this Topic for example we could develop a namespace for tiddlers that are not visible in the story or standard lists.
In reality there are not many places we need to intervene in TiddlyWiki to get a whole namespace to be developed with different qualities. That is tiddlers with an alternate namespace to be treated differently to others. Existing examples include system/non-system/shadow/temp/state/$:/info etc…
- intervening can be done in a numbers of ways including override existing core tiddlers and macros, clone and use a modified version, hide the current tiddler eg remove the side bar tag, and replace with another that has the same caption etc…
- In short modifying some filters to exclude or include given prefixes via a subfilter is going to be sufficient in most cases.
I raise this because not only can we do this quite easily but I foresee being able to make such namespace design a hackable feature of a particular tiddlywiki edition, or perhaps sometime in the future part of the core.
- It may be as simple as replacing existing filters with filters that are obtained from a config tiddler or global macro. For which we can modify.
- Adding filter operators to support a new namespace such as in the
is or all filter operatorswould be nice. - The question then is what different behaviours may we want from different namespaces? in addition to “not displayed in lists and story” in this Original topic.