I have been considering the possibility of storing a description of a tiddler in a data tiddler, so you can write a description for any tiddler, including even if it is a shadow or plugin tiddler without editing the actual tiddler. In this case the key to the data tiddler would be the full tiddler title. Then a view template item or cascade could display it when available, or perhaps in small text at the end of the subtitle.
However before starting, it occurred to me the key to this data tiddler could be extended to include a name eg currenttitle!!description and in effect the description in this case would be a virtual field, and the data entry contain its value.
We may be able to use this in a way it acts like an actual field, eg if no description, look for the virtual description or vici verci
Or we could use it for other features such as a list of currenttitle!!related-tiddlers again without touching a shadow tiddler.
This could be very helpful in annotating core tiddlers that can then be shared with others.
Perhaps all fields could be stored in such a dataset as a field level backup, especially for overridden core tiddlers, because if they change during an update/upgrade we can see a difference exists and restore, delete or merge it.
IIRC you have already proposed a similar idea here some time ago, which received some positive feedback. – Edit: Oh! Or was it twMat?
I like the idea – which I will call “extra-data” below. Here are some thoughts on it:
Pros:
Allows extra-data addition to system/core/plugin tiddlers without modifying them
For me this one is a big plus!
Easier maintenance for wikis when updating to new TW versions
Might be useful for translations?
Cons:
Splitting data and extra-data in separate tiddlers means added complexity for bundling, exporting or searching
IMHO, tiddlers being a single container for data and metadata altogether is one of TW’s wisest design choices
Added extra-data would be “hidden” and more difficult to find for newcomers.
It’s already quite the case with ViewTemplate/transclusion mechanisms and I often find it challenging to reverse-engineer where some visible components come from when there is a difference between the tiddler content and it’s visual representation in View Mode – even in my own code after a few months.
Adding another source of “not-immediately-visible” data would also add another layer of complexity
Some of the cons could be mitigated with adapted tooling, maybe even by overriding core components like export and search – quite a paradox for an idea willing to avoid system tiddlers modification
One point I could not understand in your proposal is the granularity of this new dataset: do you propose a single data tiddler for all added extra-data, regardless of the target tiddlers (implying an extended keys namespace), or would there be a data tiddler for each extended tiddler?
This design choice will have important consequences on the aforementioned tooling, especially when someone wants to export some tiddlers and the associated extra-data.
However you implement this, it would be nice if you could coordinate with @twMat — since their keywords solution is doing something quite similar — centrally storing as tiddler metadata what might have seemed tempting to store in a separate field (such as a keyword field) for each tiddler.
Compatible with your line of thought: Allowing keyword metadata to be outside the actual tiddler (on twMat’s rationale) has the benefit of playing nicely with shadow tiddlers, and (for some uses) one might want some such metadata NOT to follow tiddlers when they are exported, cloned, etc.
I’m working on macro documentation (sorry, variable documentation) and I’m allowing that same approach: the definitions for each piece of documentation can be stored anywhere. Just means that when I enter my-cool-macro into the search box, it’s the job of the tool to go find it and reveal its documentation.
But back Tones’ original question – a few times I’ve considered “virtual tiddlers”. But I usually find another way…
Thanks @tw-FRed for your considered response.
Whilst this is completely true sometimes a solution demands this, or the separation from the named tiddlers is needed. As is clearly the case when commenting/documenting core tiddlers. however If the data tiddler is not a system tiddler it immediately becomes searchable, this may even prove to be a feature that can be used to make system tiddlers searchable via a virtual field.
Here is a practical example of the use of this, install in a copy of tiddlywiki.com, make notes against any tiddler even specific fieldname without touching the tiddler. Note when a tiddlywiki upgrade comes out, upgrade your wiki, or create a new one and import your virtual fields data. Perhaps a validity check to see if all tiddlers still exist (detecting deletions), but now continue annotating fields and build up a resource over time.
Such a solution comes to reside in your wiki, it belongs to your wiki, it ages with your wiki.
With this kind of solution we do not need to concern ourselves with sharing.
I don’t want to be specific yet, more brainstorm the possibilities, I imply a single data tiddler, the tiddlername/field key allows this, however we may use more than one in a particular case as the need arises. One for author, one for the read only mode users perhaps? Perhaps we could call this “shadow tiddlers” but the term is in use.
Not in this case, I have a different concept that is similar to this, not a single data tiddler for each tiddler but an additional tiddler in wich we can load information about its parent.
One thought that arises is what if this virtual field “database” allows filter or wildcard fieldnames?
for example [all[shadows]!is[system]]!!show-code:value for show-code in virtual fields on all tiddlers shadow tiddlers, not system tiddlers.
Another thought that arises is what if this virtual field “database” allows the value to be filter?
(virtual)code-body="[{$:/config/code-body}]"
Exactly, often a limitation can be a feature. Thanks for the links.
To be sure here I am discussing Virtual fields. a field that exists external to the parent tiddler that can have a value and be retrieved “automagically” for the current tiddler.
Can you please give a little more detail. I don’t follow, but I am interested.
As they say a lot in Vietname, “Same, Same but Different”
Looking at the keywords plugin it is quite interesting, especialy the UI involved. I observe the “data tiddler” is in fact a tiddler also containing code, that stores the keywords in fields by the name of the tiddler it belongs to. This is a nice bit of code. However it effectivly presents one virtual field per tiddler, a virtual “keyword” field. Love it.
But what I wanted to discuss was the idea to have any number of virtual fields per tiddler. If the solution in this Topic were developed mats solution could just use the virtual “keyword” field and contain less code.
To bump this I will summarise the three virtual approaches raised
A Virtual tiddler for each tiddler
In which you can find additional information about the real tiddler.
Keyed with title by prefix/tiddlername eg $:/virtual/tiddlername
A virtualised field such as keywords done by @twMat
A data set containing the value of the named field keyed by tiddlername
Ability to virtualise fields keyed by tiddlername/fieldname
One data set for all virtual fields and their value
Some may find this idea that could support this interesting Expanding the is system namespace where one could hide the virtual tiddler/fields behind a separate system namespace eg; #:/ or V:/
