New Tiddler fields - guarding against naming clashes


I am in the process of putting together my first plugin - it can add two new fields to a regular content tiddler that a user has written.

Is there any kind of ‘name space’ convention in the naming of new tiddler fields so that plugins do not clash?

For instance I use a ratings plugin that assigns a rating 1 to 5 stars on a tiddler, a measure of the perceived value of the tiddler - that stores the rating in a field called ‘rating’ - it is conceivable if I was unaware I might also choose to name on of my new fields ‘rating’.

Are there any measures to ensure no name clashes on tiddler fields?

My new tiddler fields are named interval3 and last-reviewed3 - the trailing number probably makes a clash unlikely, I might add another trailing digit.

kebab-case is typically used for multi-word fields in a tiddler, while also being all lowercase.

As far as avoiding reuse of field names, you might just want to reuse the the fields that you create, rather than trying to make them super specific such as suffixing them with numbers for uniqueness.

One simple possibility is to reuse the namespacing from the plugin name for this. Plugins are typically named something like $:/plugins/username/pluginname. I don’t know if there’s any convention around this, but if you’re worried about namespace clashes, then you might try fields username-pluginname-rating, username-pluginname-interval, and username-pluginname-last-reviewed.

However, I think there is probably a better strategy. Add one level of indirection, and store the name of the field in a configuration tiddler, either as the text of a single tiddler or as a field in a more general one. Make the default value the simple name. For instance,

title: $:/me/myplugin/config
rating-field-name: rating
interval-field-name: interval
last-reviewed-field-name: last-reviewed

My description of the configuration...

This will add a small bit of complexity to filters that use this field name, but it means that the obvious field names are the default, but anyone who runs into a conflict can simply change that name.

The real advantage is that now different plugins that do complementary things with the rating field can work together. I haven’t tried this with a field name myself, but I do something similar for a tag name in my WizardNav plugin. It does some special processing for any tag that is itself tagged "Wizard". But that tag name is configurable, and you can alter this by changing the text of a configuration tiddler to "Pathway" or some such.

It works well for me.

1 Like

Reuse field name is a good habit Suggestion for all Plugin developers about field name: Let’s use Ontology to maintain Interoperability. Using namespace is not good in this view.

If you can define a good field name, others can search and use yours.

I believe in using meaningful field names, and to do so use them in a subset of tiddlers with some kind of condition such as “is a todo”, I tend to avoid ones I know are used across tiddlers in general such as “rating” but if that describes it, I try and qualify it such as “movie-rating”, if this is what it is. Or describe the field in the name eg “package-filter” which is unlikely to clash with “filter”, already used in the core. But keep in mind the “filter” field is used in tiddlers tagged $:/tags/Filter.

On or empty.html you can identify core fields.

<$list filter="[all[shadows+tiddlers]has:field[filter]]">


Or review

If I have any doubt I would use the pluginname from $:/plugin/pluginname or projectname from $:/PSaT/projectname but I have never needed to, and never had a clash that causes problems.

  • This may be because of my experience and a knowledge/information manager, or may not.
  • Of course if the solution is designed to work with other plugins, I identify which fields they use first.

I think you are right. … If you are OK with the number suffix. I think it’s very unlikely that someone else uses numbered suffixes. At least I don’t know any.

I personally use a 3 letter prefix, if I want to have my names to be unique. I use wl- for wikilabs. That’s the same prefix I use for CSS classes in my plugins.