Prevent tiddlers from having the same specific field values?

Justin_H · November 9, 2022, 4:07pm

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!

TW_Tones · November 9, 2022, 9:27pm

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]]

Justin_H · November 9, 2022, 10:29pm

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.

TW_Tones · November 10, 2022, 1:39am

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.

Justin_H · November 10, 2022, 2:18am

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

TW_Tones · November 10, 2022, 5:16am

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)

pmario · November 10, 2022, 8:13pm

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.

Justin_H · October 17, 2025, 5:20pm

Sorry to necro this thread, but I’ve found a different usecase where it would help to have a field give a notice that another tiddler has the same value.

For instance, if [[Tiddler One]] has a caption of “John Doe” and [[Tiddler Two]] also has a caption of “John Doe”, having a notice appear like the title where it says, “Caption already exists for: [[John Doe|Tiddler Two]]”

I have looked into how $:/core/ui/EditTemplate/title handles it, and trying to see how I can modify the new-field procedure in $:/core/ui/EditTemplate/fields to achieve the same thing, but I’m not entirely sure how to grab the value being typed into the new-field field of the editTemplate and use that to search other tiddlers, or even where to put the dropdown notice, as I don’t think embedding it into the procedure is the right idea…

Does anyone have any recommendations?

etardiff · October 17, 2025, 6:40pm

The easiest way to modify the field editor for a specific field(s) is through the Field Editor cascade (Control Panel → Info → Advanced → Cascades → Field Editor tab). Here’s a working package; I’ll walk you through the steps below. duplicate field values.json (1.1 KB)

First, add a new config tiddler whose text field contains filter that captures both your chosen field names and the template that should be used to display them. In my demo above, I called this $:/config/FieldEditorFilters/duplicate.

caption +[match<currentField>] :then[[$:/my/ui/EditTemplate/fieldEditor/duplicate]]
<!-- ^ as many space-separated field names as you want      ^ your modified display template for these field names -->

We’ll need to make sure this filter appears before $:/config/FieldEditorFilters/default in the cascade, so either drag your new filter tiddler before $:/config/FieldEditorFilters/default in the $:/tags/FieldEditorFilter tag-pill or give it the field value list-before: $:/config/FieldEditorFilters/default.

To make the display template $:/my/ui/EditTemplate/fieldEditor/duplicate, I started out by cloning $:/core/ui/EditTemplate/fieldEditor/default and modified it as follows:

\function currentValue() [<storyTiddler>get<currentField>]

<$edit-text
	tiddler=<<currentTiddler>>
	field=<<currentField>>
	tag="input"
	default=""
	class="tc-edit-texteditor tc-edit-fieldeditor"
	placeholder={{$:/language/EditTemplate/Fields/Add/Value/Placeholder}}
	tabindex={{$:/config/EditTabIndex}}
	cancelPopups="yes"
/>
<% if [has<currentField>] -[<currentTiddler>] -[{!!draft.of}] :filter[get<currentField>match<currentValue>] +[format:titlelist[]join[ ]] %>
	<small>
		"<<currentTiddler>>" shares its <<currentField>> value with <$list filter="[enlist<condition>]" join=", "><$link/></$list>
	</small>
<% endif %>

I added everything after the $edit-text widget.

The $edit-text duplicates the default field editor.
The conditional <% if ... %> displays its contents only if there are one or more tiddlers (not counting the current draft or the tiddler it belongs to) that have an identical value for the current field.
- If you want to check for duplicates in shadows as well as standard tiddlers, replace [has<currentField>] with [all[shadows+tiddlers]has<currentField>].
- +[format:titlelist[]join[ ]] stores any resulting titles as a single space-separated string, accessible inside the conditional as <<condition>>.
- <$list filter="[enlist<condition>]" join=", "><$link/></$list> converts the title list stored in <<condition>> to a comma-separated list of links to the relevant titles.
- You can modify the styling of this warning text however you want — just make sure it all stays inside the conditional.

Alternately, if you want all user-added fields to warn for duplicate values, you can skip the first step (where we created $:/config/FieldEditorFilters/duplicate) and simply replace the contents of $:/config/FieldEditorFilters/default with

caption +[match<currentField>] :then[[$:/my/ui/EditTemplate/fieldEditor/duplicate]]

Or go a step further and overwrite the contents of $:/core/ui/EditTemplate/fieldEditor/default itself with the modified template above.

Since our new field template deviates from the standard field editor only when duplicate field values exist, you could theoretically make it your new global default. But you may not want these warnings for all your fields… and since the filter used in the conditional is checking for matching field values on all your tiddlers, it may be a little slow in a wiki with lots of tiddlers/lots of fields.

Scott_Sauyet · October 17, 2025, 6:48pm

Very nice! I just went to try building something like this, and wasn’t even half-way there when I saw this version. Very useful!

(Although amusingly for myself, caption is one of the fields most likely to be duplicated – quite intentionally! But I can easily imagine wanting other fields to be unique!)

etardiff · October 17, 2025, 7:16pm

I tend to agree — though I can imagine wanting to avoid duplicate captions if you make heavy use of TOC macros or other components that default to displaying captions instead of titles, where duplication might make the target of a given link unclear.

I think I might also sometimes want to be notified about duplicate values in a title list. For instance, I’m a major fan of @pmario’s uni-link plugin, which expects a given alias (listed in the aliases field) to appear on no more than one tiddler.

Here’s a variant that looks for duplicated list values rather than completely-identical field values:

\function currentValue() [<storyTiddler>get<currentField>]

<$edit-text
	tiddler=<<currentTiddler>>
	field=<<currentField>>
	tag="input"
	default=""
	class="tc-edit-texteditor tc-edit-fieldeditor"
	placeholder={{$:/language/EditTemplate/Fields/Add/Value/Placeholder}}
	tabindex={{$:/config/EditTabIndex}}
	cancelPopups="yes"
/>
<small>
<ul>
<$list filter="[enlist<currentValue>]" variable="listItem">
<% if [<listItem>listed<currentField>] -[<currentTiddler>] -[{!!draft.of}] +[format:titlelist[]join[ ]] %>
		<li>''<<listItem>>'' is also listed in the //<<currentField>>// field of <$list filter="[enlist<condition>]" join=", "><$link/></$list></li>
<% endif %>
</$list>
</ul>
</small>

Pardon the lack of pretty styling; this was very quickly thrown together.

Justin_H · October 17, 2025, 7:29pm

WOW, That is exactly what I was trying to achieve! (and it works with multiple tiddlers using that enlist filter, that’s smart, hadn’t considered that might happen ) also, the written out explanation is awesome. In hindsight,

I didn’t think to use the cascade, but that makes perfect sense. Also, I didn’t know you could create a macro without naming it first in something like a let or vars or procedure.

Ah yes, I agree. I imagine something like a UUID field would be a more ideal use-case, I chose caption as it was what I use the most, and having long tiddler titles tend to be cumbersome. I modified my recent to show caption with a onHover to show the full title, so generally the same idea as the TOC.

That… is an interesting idea I may find use with that.
Thank you for pointing this out! I may add to it so if there are more than say, 3 tiddlers with a matching user field, it could say something like "<<currentTiddler>> shares its <<currentField>> value with 3+ tiddlers" or something akin to that. That will be fun to play with

etardiff · October 17, 2025, 7:46pm

In this case, <<condition>> is actually a variable automatically assigned within the conditional syntax.

<% if [tag[HelloThere]] %>...<% endif %>

is syntactic sugar for the corresponding $list widget:

<$list filter="[tag[HelloThere]]" limit="1" variable="condition">
...
</$list>

In other words, the first result of the filter is assigned to <<condition>> within the scope of the $list/condition.

This is why we need to add +[format:titlelist[]join[ ]] to the end of the conditional filter if we want to be able to access all the filter’s results — otherwise, <<condition>> would only return the first title.

Scott_Sauyet · October 17, 2025, 8:27pm

In fact, I use these specifically for TOCs

Imagine something like this¹:

˅ Jazz
    ˅ Oscar Peterson
        > Instruments
        > Recordings
        > History
          Member of
    ˅ Hiromi Uehara
        > Instruments
          Recordings
        > History
          Member of
    ˅ McCoy Tyner
        > Instruments
          Recordings
        > History
        > Member of
    > Thelonius Monk
    > Herbie Hancock
    > Chick Corea
    > ...

where I might have titles like Person/Hiromi Uehara and Person/Oscar Peterson/Instruments but still want a clean-looking TOC.

In any case, this is great stuff. Very useful! Thanks, @etardiff, for sharing.

¹ Not a real example. I’ve just recently discovered Hiromi , and now there’s a new shining star among my favorite jazz pianists…

TW_Tones · October 17, 2025, 11:45pm

This is why I feel there is a need for a set of defacts standard for field handling so as a community we can share configurations for fields and field-types that use smart filters when selecting values;

Select from a literal set of values
Select form a list of all existing values already used (duplicates accross tiddlers)
Test values for uniqueness (this Topic)
Select using a filter of possible values
Select a number from a range
Select a date
Select a color (on other fieldnames) or paste color name/code
lookup value from set of tiddlers
Insert a transclusion of a title eg image tiddler

etc…

Justin_H · October 17, 2025, 11:51pm

If you mean collecting the recommended best practices from other users to compare and agree upon as a ‘we suggedt these, but feel free to try other things’ then I 100% agree.

however, a set in stone, ‘this is the correct way and the rest are not’ approach I would recommend against. partly because the whole idea of TW is that it is a framework for you to make it do what you want it to do.

while restrictions can breed ingenuity, I think that would be counter intuitive to the core philosophy and design intent of using tiddlywiki.

TW_Tones · October 18, 2025, 12:04am

In part thats what I imply by saying “defacto standard” but even if we had a fixed or “dejure standard” it would always be at the designers discression. The key example is the current provision of the various cascades, in many cases you can bypass these.

A key issue in this community is so much knowledge exists but very little gets formalised in such a way people can make use of it without reinventing the wheel. Fine you can reinvent the wheel, but it is also nice if I could just grap a “chariot wheel” off the shelf if I need one.

I am writting a non-fiction book at the moment and one of the ideas I want to promote is for people to see when they do something once, if it may be used again, spend a little effort to make it reusable. Then, if needed a second time, you are already ahead in the time invested. This is turbo charged if the solution is added to a community library.

The bigger issue is if such solutions need to exist on top of a common base. For example generic field handling, so we can simple share a “field definition”, or as I have discovered share different field-types, because multiple fields will use a single field-type.
This is one of the best community forums on earth, tiddlywiki is one of the best open source communities on earth, but it has some clear limitations and this is one of them.

Springer · October 18, 2025, 1:17am

I see the suggestion as being mostly about the kinds of general parameters that we want to recognize as potentially applying to fields. Saying “Hey, field-value uniqueness is an attribute that we all want to have a way to document, flag, support, etc.” is different from saying things like “Caption field should take only unique values.”

I see why some people like @Scott_Sauyet are using captions for tab labels and such, where context clues are in place, and the caption wants to be short to avoid redundancy, without needing uniqueness.

By contrast, I use captions in my biblio solution for an entirely different reason: captions allow me to mix italics into a string, and bibliographic references should include italics. Since I display caption instead of title (in sidebar, tiddler title area, etc.) a uniqueness check would actually be quite desirable!

At any rate, I think @TW_Tones is right that we should be brainstorming with a broad net: “What are the kinds of attributes/constraints/affordances that are commonly in demand for field structure, and how can we recognize some basic set of these as worth developing and supporting?”

And +1 for value-uniqueness, across the wiki, being one such field-specific parameter that users can apply to fields, and remove, as needed.

pmario · October 18, 2025, 1:18am

While aliases should be unique, the plugin can still handle it if 2 tiddlers have the same alias. The aliases and alias backlinks will show the corresponding tiddlers.

But the plugin leaves it to the user to fix that.