First I would like to reserve the name Ghost tiddler for this specific application, or if not adopted my own use later.
Background
Folks an often used mechanisium by plugin and solution designers and even in the core, is to use an external tiddler to store information such as the visibility toggle for editor toolbar buttons.
- That is we have a tiddler, usualy a system tiddler which as part of its title is a target tiddlername. When listing or displaying the tiddler we can construct the title and test if it exists and/or has a value.
- This is essential if we do not want to edit a shadow tiddler
Limitations with above
- Solutions that establish such a mechanisum can not easily see if others are doing something similar.
- This creates a proliferation of tiddlers to store very simple information, often a binary yes/no, true or false. Athough usualy hidden behind a system tiddler.
- This often results in long tiddlernames which themselves consume more bytes.
- eg;
$:/config/ViewToolbarButtons/Visibility/$:/core/ui/Buttons/close-others
- eg;
- Because we have no idea of the tiddler naming conventions, different plugins and solutions use, we dont know about each other and it makes it hard to cache such lookups.
- This often results in long tiddlernames which themselves consume more bytes.
A possible solution RFC
The idea would be to provision a ânamespaceâ such as â$:/ghostâ (I may have used shadow had it not already being used) and when needed a user or solution could test for or create a ghost tiddler even by just providing a fieldname in the ghost tiddler (ie there is no template or prerequisit, or action tiddler needed to create a ghost tiddler, Just use it by setting a field to its value (which you can test for before you do so).
âMy Tiddlerâ
â$:/ghost/My Tiddlerâ
In common solutions like I discuss here RFC: Conditional UI elements Tabs/buttons and more we may use a generic fieldname eg; condition, in bespoke solutions the designer âmay name the field according to their brand or plugin nameâ such as a fieldname $:/plugin/PSaT/myplugin/conditions so it is both unique and indicates what plugin or solution introduce the field.
- The matching tiddler for the fieldname $:/plugin/PSaT/myplugin/conditions can explain its use.
Reasoning for a ghost tiddler
- provide a standard location for external info relating to a named tiddler
- The ability to review one tiddler to see the different settings that apply to it
- We can have a tiddler info tab itterate the fields and create a UI to adjust these fields. So all solutions can create a settings tiddler that appears in a shared info tab.
- This would be an opportunity to document the the changed date of a core tiddler, annotate core tiddlers, back up the tags field title before changes and much more.
- As not all will be shadow tiddlers themself, they could all be listed, transfered, deleted.
- The text of the Ghost tiddler could be used for freeform notes on the named tiddler or to act as a data tiddler with a standard record type to log activity on the target tiddler or collect other useful information relating only to that tiddler. Eg edit date history and total bytes at edit.
- Another use is for the ghost tiddler to contain a child-filter that identifies the children such as for
$:/ControlPanel
there would be a$:/ghost/$:/ControlPanel
tiddler containingchild-filter="[tag[$:/tags/ControlPanel]]"
- This would allow the settings to be listed as a heirachy with each tab that contains other tabs also setting their child-filter (or tab/menu filter)
Advanced ideas
Perhaps the adioption of another namespace such as &:/
which is also a system tiddler as discussed here Expanding the is system namespace then we can save more bytes with ghost tiddlers found at â&:/
tiddlernameâ or even âđ»:/
tiddlernameâ
Stratigic analysis and comments wanted