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.
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.
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!
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 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.
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
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.
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.
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.
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 [[ ]].
