Prevent tiddlers from having the same specific field values?

Is there a way to prevent two tiddlers from having the same field value, like they already do with titles?

I’m experimenting with different ways to name tiddlers and one of the ways has relatively long titles, so to deal with that I made a macro that links to a tiddler with a specific fields value.

I call it! a TID (tiddler Identification data).

I think it’ll be easier to show than tell though.

\define tid(desc, tid-num:'0')
<$list filter="[tid[$tid-num$]]">
<$link>$desc$</$link>
</$list>
\end

<<tid 'Dave' 'dave#a1'>>

This is designed specifically for use with a field of ‘tid’, but if you wanted to link to a tiddler with a specific field that wasn’t tid, I took light inspiration from linkify and did that too.

\define tid(desc, tid-num:'0', field:'tid')
<$list filter="[$field$[$tid-num$]]">
<$link>$desc$</$link>
</$list>
\end

<<tid 'Davey J' 'Davey Jones' 'caption'>>

Still defaults to the tid field, but if you wanted a tiddler that has a caption of say, ‘Davey Jones’ you could do that.

I put the specific field on the end so if you wanted to use just the tid field, you wouldn’t have to do <<tid 'Dave' 'Davey Jones' 'tid'>> you could just do <<tid 'Dave' 'Davey Jones'>>

I’ve tested what happens when two tiddlers share the same value and it makes them both appear, but no way to tell the difference between the two without hovering over them or navigating to the tiddlers in question.

so if possible, I’d like to prevent the resuse of the same value!

1 Like

Perhaps her are two approaches to this;

  • When listing tiddlers that have the same value add logic to show;
    • There is more than one
    • Perhaps show number then eg: oldest first (by created date)
  • Make the tool to set the tiddler title in the field and stop entry of a value already set in that field.

The following filter retrieves a list of unique values found in fieldname;
[all[shadows+tiddlers]each[fieldname]get[fieldname]]

Well, my way of doing it currently is,

Tiddler: "Joe Dirt (Contractor)" Field(tid): "JoeDirt#01"

so if there is another Joe Dirt, when adding a tid field for them, it would tell me "There is already a tiddler with the tid of 'JoeDirt#01' " so I would know to make it ‘JoeDirt#02’ if I had already tried making it `JoeDirt#01’

Edit: The use-case for the macro above and why I want to have unique tid field values is for a friend of mine who wants to use the ‘windows explorer’ naming convention as they call it, where they have it as “…/NPC/Contractor/JoeDirt” so they could use the tree macro, just for context.

1 Like

Understood, I started something similar, hoping to build an equivalent to windows folders for placing tiddlers or importing from Windows so one can annotate folders with tiddler content, open the folder view in the browser etc…

  • We do need to deal with the same sub folder name (OK as uses full path) and duplicate tiddler/filenames - needs something like you have.

The only thing I’m trying to work out is how to make the tags a bit more appealing to look at.

I don’t use them in the standard tiddlywiki way, but if someone were to click the new tiddler here button on a tiddler using the explorer format, the tag would be way too large.

I was looking at modifying the tagtemplate to also use the tid field, but at that point I’m 1. modifying a system tiddler, and 2. would still need to prevent the reuse of tid values.

Something I found out is using the caption for tags will have the same unfortunate issue :sweat:

Look at the TOCP plugin in the wikilabs plugin library

This allows a new here to populate the parent field (customisable) instead.

config_wikilabs_PluginLibraryWL_latest.json (352 Bytes)

As Tony pointed out the tocP TOC parent plugin may be an option here. … But it doesn’t use special field values to link between elements. It still uses the tiddler title. …

BUT creating the TOC-structure uses a “parent” field by default. … The field name used can be configured. So it’s possible to have several TOCs and 1 tiddler can be part of different structures.