[Proposal] Updating field handling functionality in TiddlyWiki

[TW_Tones]

@Scott_Sauyet

I haven’t ever investigated how the type is used to give different edit/view templates, so I don’t know how much work this would be. But it might well be worth investigating.

@Scott_Sauyet I thin @pmario starts to illustrate the complications with the type field, I think there is a resonable argument unless we are dealing with mime types and other content variaents it is best to stay away from the type field. I have done a number of deep dives into it a few times, the following was my conclusion.

• Type is more abour mime and system types for the content
• As a result I have consistently used another field object-type to differentiate between tiddlers with different functionality. I use object because it is often a general term for what a tiddler is eg contact, recipie, chapter etc…
• Perhaps start another toipic if you want to explore the type field further

@Springer

For me, whatever we use has to be readily accessible via keyboard. The section character is opt-6 on a mac. Not sure what it is on other platforms, but it’s supported in most fonts and isn’t at risk of turning into an inscrutable □.

Perhaps I will soon illustrate the following but I do think there are some missunderstandings here;

• We dont need to enter these field namespace from the keyboard, as we may control the creation process
  • Most unicode can be entered at the keyboard, you just need the code
  • Making these hard to create without using the creation process is part of its value
  • clone or title copy paste is a simple work around if you have already one tiddler with that title
  • All the characters after the “symbol chosen” are searchable in standard search

Missunderstanding about standard and system fields

Discussions here and over here;

@Springer

@pmario

I think we will definitely need some support from the core, especially because there are default core fields that are hidden by default, like modified and so on. Messing with them, has potential to cause confusion.

Since modified and created aren’t shown in the field-editing interface, I don’t see that my proposal/proof-of-concept really does anything to facilitate “messing with” them in any way (though I do think access to modifier and creator — as links to templated field overviews — will be especially useful in multi-user wikis!). My design also doesn’t make any automatic links to type or tags or text, since those also aren’t straightforwardly present in the usual edit-field array.

I would contenst some recieved wisdom here. It is easy to reuse standard and system fields with impunity in most cases. for example it dose not make sense to reuse plugin-type or modual-type, and I always leave the created and modified names and dates for the system to maintain.

But not withstanding those, a field means what you intend it to in the context in which you use it.This is one reason I make use of the object-type field to set a type (used) of tiddler. You can always scope the field and even its meaning as belonging to an object-type or another indicator like a tag. This permits reuse of existing standard and or system fields.

• A wise designer always qualifies a field eg; if the already depend on the color field they will use an alternate border-color, or object-color etc…

The display and edit of fields. There is no problem if a designer makes available an existing field to drive some process, for example the modifier. Even if tiddlywiki allready provides some handling eg in the subtitle, the designer can introduce it to the view template.

The full argument may run down some rabit holes but I do want to make the point there are very few cases where people want to reuse standard or system fields and when they do in many cases it makes no difference.

Conclusion

Keep the existing use of standard and system fields in mind but there is largely no need to treat them much differently when adding field handling.

• If anything this is a key argument for field tiddlers to have a prefix
• It suggests we could document the existing fieldnames more.
  • With extended field handling we can see how they are used for example illustrated Proposal: render fieldnames as links, and see what's possible with fieldname nodes! where we present the values and tiddlers using the field.
    • This helps us to reuse the fields as well but informing the designer.