With $action-setfield we can update several field at once in an easy way. But for indexes’ we can only do it one at a time by using $index and $value.
As a great user of dictionnaries, I think it would be cool to have a $ation-setindex that would be the mirror of $action-setfield (exchanging what can be done with fields and indexes). intended example of use below:
<$action-setindex $tiddler=target index1=value1 index2=value2 index3=value3
$field=comment $value="how cool!"/>
Of course this can be gone wrapping it in a list widget but I support you desire for this simpler form.
Basically you want a way to write multiple index values using a set of keyword value pairs.
However we also want to have one index to a record with multiple named attributes. if you consider action setfield it is only referring to a tiddler and its various fields.
So in short to achieve what you want is already possible, but when providing a simpler solution you need to consider the broader set of desirable features.
There has being a long standing desire in the developer community to deprecate “data tiddlers” including @jeremyruston but personally I think this is a mistake. I believe strongly we should permit all practical data structures as long as they do not compromise the greater method. In some ways data tiddlers are just “packaged” potential tiddlers. Their title key is out of the search dropdown.
To setup my context, I’ve written a database mechanism within TW where each record is a tiddler. To have a complete freedom of names, I had to use index because some fields name are already taken (like //title// in particular!) and some restrictions apply on field names whereas there is none for index (except including an end of line or a semicolon).
Each record is a dictionary. They are also system tiddlers to avoid any apparition in the recent tiddlers list and apparition in the normal lookup.
@TW_Tones : Are they what you call //data tiddlers// or you thinking to an other thing?
I just saw the field naming standard documented here is incorrect, instead see . This may change things for you.
Unrestricted Fieldnames and the New JSON Store Area
The major change in this release is that the format used to store tiddlers in TiddlyWiki’s HTML file has changed from an HTML DIV-based format to a new JSON-based format. The consequences of this change are far-reaching. They are thus the primary rationale for bumping the version number from v5.1.x to v5.2.0:
Firstly, the characters that can be used in field names are now unrestricted (just like tiddler titles), making it possible to use fieldnames like
My^Fieldor☃️. This has become possible because every other part of TiddlyWiki was already capable of dealing with unrestricted field names apart from saving as an HTML file.Secondly, external tools that read, write or otherwise process TiddlyWiki HTML files will need modification to understand the new store area format. The details are documented in the /dev wiki.
However, yes freedom of names independant of titles is a use for data tiddlers, however it is simple to add and remove prefixes to make new tiddlers with “the same name”.
Officially data tiddlers are defined here, but informally I would consider any tiddler within which you store independently accessible pieces of data.
Sometimes one can get around that by using a prefix. For example, in my work I often use the prefix @ for fields whose names are derived from user input (or otherwise unpredictable).
Is the new json storage for field meaning that the handling of json previously brought by jsonmangle will become navive?
As for prefix, yes, they are a quick fix for that problem.
But for purely data tiddlers, indexes are giving an immediate glimpse at the tiddler contents, which is handy.