[Idea] Tiddler types and features - a user fields approach

[AnthonyMuscio]

Indecently I think the "horse as bolted" but I have being disappointed the system uses the "type" field when in reality it would have being better as content-type or mime-type that is qualified.

An example of where this is causing complications is

• Proposal: Maybe filter tiddlers shouldn't be text/vnd.tiddlywiki, but instead be its own type. Proposal: Maybe filter tiddlers shouldn't be text/vnd.tiddlywiki, but instead be its own type. #4395

New and naive users, as I was once, may be inclined to use type to describe the type of tiddler it is such as todo note bookmark filter etc...

• There are a few cases in tiddlywiki where overly generic names in a way steel valuable names that could have being more meaningful to a larger audience.
• Perhaps we can endeavor not do do this going forward?
• Here I propose being one step a head providing some suggested fieldnames for common functions to help set a standard
• Fieldnames that do not consume standard or generic names

It would help if the core set a standard for some kind of logical "tiddler type" field such as tiddler-type, so all designers and plugin developers could set custom tiddler-types and provide the handling for the type they are defining, especially now with the cascades, by setting a standard field which can only contain one value at a time, thus a tiddler can only have one tiddler type at a time, but not be confused with the existing type field.

In a similar vein we could introduce a tiddler-features-list field. Operating not unlike a type but in this case a designer developer can add a feature name to this common field, along with other features. In this case add it with list ops, for example lets say I make an "archive" plugin any tiddler with the archive feature gains an "archive button" that store tags in the archived-tags field, sets an archive date-field.

Now with the multiple possible tiddler-types or tiddler features, solutions using these fields could be designed in there settings tab to detect if the tiddler-type or feature is already in use in the wiki and provide a config option to use another if needed.

• of course being able to register a tiddler-type or feature in a central repository all can see would also be a quality feature, such at one designer and developer can write solutions that are aware of and can even make use of the tiddler-type or features set by another developer.

In both the cases of tiddler-type and tiddler-features-list fields we could build a cascade mechanism to support their use.

• At a minimum a response to this post I would like to see is perhaps publishing a few defacto standard fieldnames to support the the on wards development of tiddlywikis by users, designers and developers, that are not simply "imposed by the core, for the purposes of the core" but to add a standards approach to handling common issues wiki users can predictably face.
• We would perhaps call these standard "user fields"

What do your think?

[Jermolene]

Indecently I think the "horse as bolted" but I have being disappointed the system uses the "type" field when in reality it would have being better as content-type or mime-type that is qualified.

I absolutely agree. The "type" field has a low level, system feel to it because the user is not entirely free to use as they please.

I now think it should have been called _mime_type or _content_type. The idea would be to reserve field names with a leading underscore for the system; we already partially implement this convention with fields like _canonical_uri and _is_skinny.

As it was, TW5 inherited all the basic field names from TWC.

An example of where this is causing complications is

• Proposal: Maybe filter tiddlers shouldn't be text/vnd.tiddlywiki, but instead be its own type. Proposal: Maybe filter tiddlers shouldn't be text/vnd.tiddlywiki, but instead be its own type. #4395

I think the only complication in that issue is choosing the best MIME type to use for filters; otherwise it's a good idea with no blockers to implementation.

New and naive users, as I was once, may be inclined to use type to describe the type of tiddler it is such as todo note bookmark filter etc...

Absolutely, it's a reasonable assumption for new users.

• There are a few cases in tiddlywiki where overly generic names in a way steel valuable names that could have being more meaningful to a larger audience.
• Perhaps we can endeavor not do do this going forward?
• Here I propose being one step a head providing some suggested fieldnames for common functions to help set a standard
• Fieldnames that do not consume standard or generic names

As you say, we can't change some retrospectively, but we can certainly keep to the underscore convention in future.

It would help if the core set a standard for some kind of logical "tiddler type" field such as tiddler-type, so all designers and plugin developers could set custom tiddler-types and provide the handling for the type they are defining, especially now with the cascades, by setting a standard field which can only contain one value at a time, thus a tiddler can only have one tiddler type at a time, but not be confused with the existing type field.

I always use role for that purpose, but that's a convention that is not present in the core. Perhaps we should add a new edit template segment for editing the role field, and start to use it properly in the docs and core tiddlers.

In a similar vein we could introduce a tiddler-features-list field. Operating not unlike a type but in this case a designer developer can add a feature name to this common field, along with other features. In this case add it with list ops, for example lets say I make an "archive" plugin any tiddler with the archive feature gains an "archive button" that store tags in the archived-tags field, sets an archive date-field.

That sounds like a useful convention, but I'm not sure it is universal enough to be part of the core. Perhaps the question for the core is how can we support users in understanding/documenting the field names they are using.

• At a minimum a response to this post I would like to see is perhaps publishing a few defacto standard fieldnames to support the the on wards development of tiddlywikis by users, designers and developers, that are not simply "imposed by the core, for the purposes of the core" but to add a standards approach to handling common issues wiki users can predictably face.

Perhaps you could give some examples?

• We would perhaps call these standard "user fields"

With the underscore convention, "user fields" are all the fields that don't start with an underscore. There are of course some "user fields" that are defined by the system (title, tags, modified, modifier etc.), but the user is still (largely) free to use them however they see fit.

[pmario]

... thus a tiddler can only have one tiddler type at a time, but not be confused with the existing type field.

It think that's not true. ... eg: If I have codemirror active and edit a Stylesheet, I would like to have type: text/css, so the syntax highlighting works as expected. ... Even if I use TW macros

In view mode I may like either text/css or text/vnd.tiddlywiki depending on what I want to see. The source or the rendered version. Once tiddlyspace was still a thing I did use. view-type and edit-type fields in my themes to make that happen.

[pmario]

The idea would be to reserve field names with a leading underscore for the system; we already partially implement this convention with fields like _canonical_uri and _is_skinny

So we may change code-body to _code_body ... Where I personally hate the second underscore, because it makes it hard to type.

[Jermolene]

So we may change code-body to _code_body ... Where I personally hate the second underscore, because it makes it hard to type.

Perhaps it's too late to change it, but we could certainly introduce it as an alternative, and make it the preferred one.

[pmario]

We may deprecate code-body because we didn't introduce it that long ago. And make _code_body the default. With v5.3.0 we may be able to get rid of code-body again

[AnthonyMuscio]

code-body is not likely to interfere with other user names, sure provide a _code-body but this is less important. Not many will want to use code-body for their own purpose. I personally built a solution with the show-code field which I felt was more meaningful.

The key idea is to carefully select some well named user fields who's purpose going forward is something many users may wish to use, in their designs that would benefit from a shared naming standard.

I am not so much talking about how to name core fields, except they not use generic names, I am talking about setting some guides on user fields for common use.

• This needs a small group of active designers and developers to identify common key user fields and providing guidance to help us adopt the same field names. view-type and edit-type may be other examples.

I would be reluctant to propose the use of "role" because a person could have a role in their job.

• tiddler-role may work for what role the tiddler plays, and it has such an explicit meaning relating to tiddlers that its unlikely to clash.
• However tiddler-type is more direct.

Other possible naming guides may be using a suffix of -list for lists (multiple entry fields), -date for dates.