What is in a tiddler? tiddler types and how we handle them

The following is a high level discussion about classifying tiddlers in wikis to explore what alternative approaches are in use and forshadow some useful code patterns.

  • It has some learning value but also seeks to know what you think.

Tiddler types with tags:
For a long time of course people have used tags to indicate a tiddler type such as the tag “project” or “todo” and can also be used to drive different viewTemplates and now cascades.

  • Using this approach the one tiddler could have more than one tiddler type at the one time, unless we enforce the use of only one tiddler type at a time.
  • This is the most common approach to classifying tiddlers across different solutions and plugins perhaps due to the compatibility allowing a tiddler to have multiple “types” or a lack of a field standard (see below).
  • Because we use the tags for other classification’s some of our code needs to test each tag on a given tiddler, to see if it represents a “tiddler type” which can add a little complexity.

Tiddler types with a common field:
I have myself long adopted the object-type field to indicate different tiddler types (separately from the type field which is for mime types). The object-type will contain a value like project or task and can be used to drive different viewTemplates even cascades.

  • Using this approach each tiddler can have only one object-type at a time.
  • Sometimes its useful to force a tiddler to only have one type at a time.
  • Using this method all plugins and solutions used in the same wiki may need to know about this standard and it precludes multiple tiddler types at one time.

Tiddler types with a Specific field:
You may be aware that various solutions and plugins out there currently adopt their own fieldnames to classify one tiddler type vs another.

  • This is a good independent approach but it means open solution or plugin is not aware that another solution using a different “tiddler typing solution”. It is thus hard to get such solutions to be aware of each other because there is no agreed standard.

What other methods exist?
There are other ways to classify tiddlers or assign a tiddler type;

  • Such as title prefixes and suffixes. Personally I have argued against the use of “compound titles” elsewhere because to make use of the information in the title, you first need to deconstruct the title.

Do you know any other ways to indicate different tiddler types?

  • Please let us know in a reply

Where to from here?
I hope the above clarification helps some users understand the options we have but I am reaching out to the community asking you to share what you do. I want us to “keep an open mind” however;

  • It seems to me that if the community adopts a more sophisticated “de facto standard” for handling tiddler types we could simplify the code patterns we need and still allow different plugins and solutions work together in independent or integrated ways.
  • I have in mind an approach which I will share soon, but setting a community “de facto standard” for handling tiddler types will have great value and we can develop shared support tools.

Let me know what you think, your answers need not be expert, just how you see it.

1 Like

I think expanding on the naming of the fields used by default would improve TW for users.
Rather than having one field named type that we cannot use for more custom uses limits users to picking some other field name that may not look as appealing to them.

The only downside is a potential issue with backwards compatibility, but I’m not sure if this can be overcome with the TiddlyWiki upgrader, but…

I’d like to propose:
content-type (like the field placeholder text says) instead of type,
so that type or tiddler-type can be used to denote what the user wants it to be, like a journal, or a template, or a todo list, etc.

plugin-status instead of status,
so users can denote the condition of the tiddler itself, like if it isn’t finished, if its broken, if its about a friend, etc.

plugin-version instead of version,
for the same general reasons as status. The same can be said for other plugin-related fields, such as name, which in the past I have mistakenly used for denoting the name of someone the tiddler was about.

Ultimately, this way leaves type and status (and others) for beginners to adopt for their own use-cases, without needing to use longer field names, or potentially messing up the TiddlyWiki with incorrect field values in the two fields discussed above.

As for how I organize my own tiddlers though,

I currently use tags with the prefixes of Type: and Status: since I can easily click on them to get a dropdown list of all of the tiddlers tagged with them, as well as filtering using different combinations of tags, just out of convenience.

I have been playing around with using fields instead, such was the reason behind my discussion on using the tabs macro to auto list all the tiddler-type and tiddler-status field values.

I tend to think of tiddler types primarily when assigning custom ViewTemplates, and in addition to “all tiddlers with a given tag,” “all tiddlers with a given value of field X,” and “all tiddlers with a certain prefix/suffix,” I’d include “all tiddlers listed in field Y of any other tiddler.”

  • e.g. if [[Fort Worth]] appears in the “birthplace” field of a tiddler, I can reasonably infer that “Fort Worth” is a location and apply a ViewTemplate based on that assumption - even if I haven’t made the “Fort Worth” tiddler yet.

I’m not sure how this sort of meta-assignation would fit into your standardization goals, though, or even whether it needs to.

Perhaps it should. I have already being looking at tiddlywiki in a similar way, trying to learn as much as I can from what “information it has”, to simplify what we have to do.

  • For example as soon as you name a “tiddler type” you should be able to click a button to create custom lists, sidebar tabs, templates or view templates for that tiddler type.
  • Fields: as soon as a tiddler has a “tiddler type” then you can,
    • find all fields defined in all tiddlers sharing the same “tiddler type” and present a form allowing you to set those fields, on any tiddler with that tiddler type.
    • That is by adding a field to any instance of a given “tiddler type” all such tiddlers can inherit that field. Wow if you ask me :nerd_face:

I cant agree with you more on there “bad choices of fieldnames in the past” but I am confident most of these of these are irreversable.

  • I will share later an idea which allows a tiddler to have more than one “tiddler type” at once, as is currently the case of you use tags for this.
  • In this case actually the use of the “types” field may be practical.

But it was wrong for type/status/version to be used by the core.

8 posts were split to a new topic: Compound Titles

Indeed! Virtual tiddler types have been vital to some of my projects, and it’s tremendously useful to be able to peek into any “node” to see its various relational connections (based on filter-defined connections to other tiddlers’ fields) even though it doesn’t “exist” (as a tiddler).

This is exciting! Sometimes I clone the “new journal” button, and do something similar to set up a kind. But if there were a sort of routine around how that happens, so that setting up a new kind is as easy as naming it and setting up something like its “archetype tiddler” – that would be amazing. (As it is, I end up doing lots of cloning, to get the fields for a given type already present… or using a dynamic table for the things that are structurally isomorphic. Shiraz dynamic tables are great for efficient creation/population of fields, just by toggling into edit mode, and adding data to the columns in question.)

I find my projects always move back and forth in a dialectic between:

(A) deepening the structure around clearly-defined types (authors, excerpts, definitions, classroom-sessions, quiz-questions, etc.), and finding ways to streamline database or table-like structure around these, and

(b) free-form exploration, miscellaneous notes and connections (the kind of thing an old-fashioned database could never do on the fly).

What’s fascinating to me is how often an idea that starts out as a free-form note (a tiddler about this or that speculative idea) eventually grows into what looks like a member of an emerging kind – if and when I devote more attention to it. :slight_smile:

-Springer

1 Like
  • This is for me a fundamental quality of playing in the tiddlyverse
  • But I expect it is self similar to the real universe,
  • We discover/rediscover fundamental truths through using tiddlywiki
1 Like

Tones, maybe my post in response to @SnapSam

already does most of this:

It sets up a view-template element such that whenever something is a tag (i.e., has tiddlers tagged under it), you get a dynamic table showing exactly the fields that exist for tiddlers so tagged.

I remember when I discovered that Dynamic Tables can use filters not only to determine the rows, but also to determine the columns. It’s so powerful!

Then once the automatic table is there, you can go to town with realizing things like, “Oh, it turns out I specified a url field for one of these tiddlers (or exp-date or card-on-file), and that was a great idea; let’s round out the column with corresponding url-field data for the others…”

-Springer