Spaces in field names

Are there any landmines to worry about if I use spaces inside field names? I know I can use them. I’ve tested that, but are there any places where these could cause problems for the unwary?

This would be for a wiki I would expect to be copied and extended by inexperienced TW users, so if there are any cautions at all, I’d like to know about them. Using field names with spaces would offer a slightly nicer user experience, but I wouldn’t do so if they might cause the users problems.

1 Like

This does not answer your question. What I do is write an EditTemplate. Depending on the tags selected the template provides appropriate edit controls specific to those tags. In this example I have a tiddler tagged as “event”, so all fields associated with an event appear. See the section at the bottom where user edits caption and date.

In this way I can design the field names as I want. The label is what the user sees. I also provide a control to hide/show the TW field edit controls.

1 Like

Thank you. This is currently for things I’m discussing in Demo: Periodic Table.

I am actually already using a similar indirection technique, and the code from @TW_Tones that I started with did so too. I just don’t know if it’s necessary. In Tony’s case, I’m pretty sure that he was simply using the field names from the CSV he imported, and I kept up the technique. But if I could simply be using “Atomic Number” instead of “atomicnumber” for the field name, it would simplify things, especially if this were to get used by TW newbies.

But I want to thank you for pointing me to something that I hadn’t thought about but will be using soon: the possibility of using edit templates dynamically based on the presence of certain tags. That will clean up several things I’m trying to do. Thanks!

1 Like

IMO this will probably work but I would go with atomic-number for all field names. No need think about naming conventions like uppercase, lowercase and spaces. 2 rules: … all lowercase and words separated with dash. … This will work everywhere and will not cause any problems.

What if I would like to see “Ordnungszahl” instead of “Atomic Number” ? … For future proofing and translatability, imo the fields should be independent from the text which is shown to the user.

With that concept in mind, there should be less problems if the UI should be translated in the future. If the English notation is hardcoded into fields it will probably cause problems in the future.

Just my thoughts

Yes, this makes perfect sense. Thank you. I’ll change the names to kebab case, keeping my current translation mechanism for the moment but plan on adding i18n soon.

Thanks for the help!

  • I question this idea, not with the interface, but yes with the filenames.

I like the apparent readability of fieldnames containing spaces but when writing wiki text code a space is a common delimiter, which means you need to be carful and look more closely to stop or fix errors in your coding.

  • Personally I reserve this broader naming feature in fields for when it really is necessary, such as to store a tiddler name as a fieldname. But I have not done this yet.
  • In the meantime I am sticking with “fieldname-with-space” as it is not only clear and easy to read but it allows parameters such as fieldname=fieldname-with-space

However when it comes to building forms and user interfaces we may want it to look differently, more like common writing here are three approaches; Lets say we has the field short-name

  • When ever displaying this field provide the label “Short name:”
  • Create a macro to generate “Short name:” from short-name
  • Create Field definition tiddlers that include a caption field you retrieve when needed.

I have built field definition solutions multiple times and believe we should look at making fields a first class citizen of tiddlywiki like we do tags, tags have tag tiddlers that can/do contain more information about the tag. But field definitions could take this further specifying field captions, values (filter) and a lot more.

  • Each field should also be given a field-type which defines how to handle the field in view, edit, selection, search, picker etc… because there are a lot less field-types than possible fields and it becomes reusable for any new field.

The thing is any multiword fieldname is lowercase and hyphenated as a rule with its caption replacing hyphen with space, and sentence case, keeps things easy, safe, reliable.

I’m not there yet, but this is definitely my direction.

This may not apply to your current project, but if at some point you want to use a great plugin made 3 years ago … it might break.

I’d love to hear more, although I have removed the spaces in my current project, and am proceeding without the need.

Up until v5.2.0 (released on 3rd October 2021), tiddler field names could not contain spaces, and could only use lowercase letters, numbers, and a limited set of symbols (such as dash, underscore, and dot). If you want to ensure that you are backward-compatible with a plugin that was written before then, you should only use fieldnames that conform to the pre-v5.2.0 field name restrictions.

ref: https://tiddlywiki.com/#Release%205.2.0

Hi @clutterstack I’d like to learn from your source code. I have made something similar Smart Form plugin - beta release - Display different form based on the tag you add

But that uses ReactJS, and wasn’t complete yet. I’d like to see if your solution is better, then I won’t need to continue my plugin.

Also I’d like to ask, can I use colon in field name? Many ontology field name has colon, for example, cal:completed
in http://www.w3.org/2002/12/cal/ical#
as suggested in solid-focus/Task.ts at 5db6787fcd9823b14b8062923dcfb9805a56a463 · NoelDeMartin/solid-focus · GitHub

See https://tiddlywiki.com/#Release%205.2.0 for when Unrestricted Fieldnames and the New JSON Store Area was introduced.

  • characters that can be used in field names are now unrestricted (just like tiddler titles)

This means you can use “:” and almost anything else. But personally I would avoid symbols and quotes commonly used in wiki text and as in the case of “:” is is only used at the start of a line, so don’t use it there. Also avoid quotes and [[ ]].

  • Personally I would also avoid spaces unless necessary as these act as a delimiter (to seperate items) in many cases.
1 Like