Advanced Field usage

#1

This is a discussion about the use of fields in TiddlyWiki.

This is in part stimulated by the 5.2.0 Pre-release removing many of the field naming rules that have applied up until now. This feature introduces substantial freedom to users and designers alike, when first discussed many saw this as an opportunity to extend the use of fields by using tiddler titles as a fieldname.

However with great freedom comes responsibilities and there will be value in developing de facto standards so we can understand what our fellow community members are doing, and maximise the possibility of backwards compatibility.

The 5.1.23 and earlier field naming rules are;

Fields can only contain lowercase letters, digits and the characters underscore (_), hyphen (-) and period (.)

There is a fair argument to stick to the older rules so your macros, plugins and tiddlers will work if transfered to a 5.1.23 or earlier version of tiddlywiki. Some people may not want to upgrade just because your tiddlers were made on 5.2.0+, sometimes a particular plugin may not (yet) work in a newer version so people want to stay with the earlier version.

Now in 5.2.0+

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

There are compelling possibilities with this fieldname freedom and this thread will discuss them, however I think it is wise only to make use of this new freedom if it has that compelling reason, at least initialy.

Please initiate discussions in this thread to discuss ideas, methods and warnings making use of this new found freedom.

#2

Fieldnames using tiddler titles

One key possibility that many of us are looking forward to is being able to use a tiddler title as a fieldname. Why?, because now we can link one or more tiddlers to another tiddler by creating a field named as a tiddler title. The value of the field is then free to contain information about the type of relationship one tiddler has with another.

Issues;

  1. Will and how will relink handle renaming titles, when it may also be a fieldname?
  2. How can we test that a fieldname is also a tiddler title?
  3. Should we use [[tiddler title as fieldname]] and/or just tiddler title as fieldname? the [[ ]] could assist in addressing 2. above
  4. If we wanted users to have access to a list of possible values to assign to a fieldname that is also a tiddler title how do we determine to which fields this applies? again this follows from item 2. above
  5. It will now be possible to have wikitext in a fieldname, such that when used it is wikifield
    eg; This title __includes underlined__ content

Comments
I think there may be value when using a title as a field name to indicate that is, what it is, with a prefix or square brackets eg [[Tiddler title]] or [[onewordtitle]] or title: Tiddler title so the Above issues can be addresed eg: if a fieldname has the prefix [[ or title: then it is also the name of a tiddler. But then how can relink handle this?

I would love to hear your thoughts

#3

Sadly no replies;

Given 5.2.0 is now in production and I have started playing with extended fields here is a recent observation;

{{{ [all[current]fields[]!is[system]] }}}

This lists all the fields in a tiddler, except by using !is[system] it will not list a field named $:/system-field.

This means there is already a component of tiddlywiki that treats fields in the namespace differently because in filter a fieldname is just a title and can be a system title or not.

This suggests to me it would make sense to filter out fields prefixed ”$:/" from the dropdown list of new fields (perhaps unless indicated) so the system prefix can be used for in tiddler temp fields or to name fields by tiddler names that we do not want to appear in the drop down through out the wiki.

Illustrated below;

  • The tiddler with the field dropdown is here $:/core/ui/EditTemplate/fields
    • Then uses filters defined in fields of $:/config/EditMode/fieldname-filter
  • Fields can still be hidden globally by setting
    • $:/config/EditTemplateFields/Visibility/$(currentField)$
  • However so far I have not identified how to exclude fields prefixed with $:/

Snag_4dfcdfd
Snag_4dfcdfd1144Ă—697 65.4 KB

#4

Yeah, definitely cool.

But there is no ice cube’s chance in hell that I would ever do that.

Simply because of the way I operate.

Having field names that match tiddler titles, that works A-1 if one never never never, never ever never changes one’s tiddler titles.

Me, I change my tiddler titles all of the time: reflect a tiddler’s scope change, or clarify tiddler purpose/whatever, or satisfy a dinky refactoring need, or satisfy a whim of the day, or part of a slow series of repeated iterative/incremental “good enough” tweaks until I look upon it and think: “yeah, that’s right”. Etc.

Blessed are those with the foresight to create a tiddler title and say: you, tiddler title, will be as you forever more.

This kid, when needed, wants to look upon any tiddler title and say: you no longer reflect current reality, and thus you will surrender to change, for I designed all to allow me to change you at any moment without heartburn.

1 Like
#5

Careful. What if a TiddlyWiki has a field name in use that isn’t necessarily related to a particular Tiddler Title in use.

Easy to unwittingly change something that wasn’t intended to be changed across the board.

If going that route, one would not want TiddlyWiki to automatically allow creation of a tiddler with a title that matches the name of an already existing field.

I’m thinking TiddlyWiki (or relink) would need confirmation upon creating a tiddler with a title that matches an already existing field name, and vice versa.

And I figure the tiddler import process would need some significant tuning, should you import a tiddler that has field names that match the title of a tiddler belonging to you, or has a tiddler matching some field name you have in use.

Maybe. I dunno.