Great ideas @Springer and a number I too have explored. Like you despite a big conversation over here [Proposal] Updating field handling functionality in TiddlyWiki I am taking it slowly because I want to establish useful, core agreeable solutions not unlike your own.
There are other ways to handle fields, and I am also experimenting with these so any solution does not limit the other methods eg;
- fields whos name matches a filter eg
suffix[-link] - fields whos value has a protocol prefix value that begins
http://Andhttps://…
A comment on the direct/indirect approach, awkwardly I would say all of the above, including to allow a set of tiddlers to have their own custom set of “field definitions”. There are multiple ways to implement this and although complex to design will make them easy to use.
- Such as a custom cascade for the “file tiddler” naming standard to be applied on a given tiddler or by default.
- I really do favor a special prefix that is not a system one such as a unicode character. Still in standard search but clearly different.
- We could do this for user tags as well.
- I really do favor a special prefix that is not a system one such as a unicode character. Still in standard search but clearly different.
- A cascade for how to view a field in addition to the current how to edit a field.
- Eg color is a number a swatch or both?
A clear discovery is if we created 100 fields they would possibly only have a dozen types such as short text, current text, text area, color, date/timestamp, title, title list, number etc… so I do favor an additional layer below called a field-type (you would set this in a field tiddler).