[Proposal] Updating field handling functionality in TiddlyWiki

[etardiff]

@TW_Tones

First this is all moot, because you choose the prefix. Do as you wish.

I mean… do we? I know you were considering a implementing a config-tiddler cascade that would search for relevant fields on tiddlers whose titles fit any of several proposed patterns. I think this adds complexity (and perhaps some rendering time, on a tiddler with a lot of fields), but if it works, then you’re right: no one is technically required to use a particular naming scheme. At the same time, shared tweaks and solutions are a cornerstone of the TW community, and it’s much easier to share them if we can all agree on some general naming conventions. I think whichever convention you promote as the preferred "default’ (or the one that’s used by the core, should this make it to the core) is likely to become the de facto standard. So I think it’s worth finding one that “works” for the most users, and I commend you for spearheading that discussion.

Just to clarify my stance a little further…

@TW_Tones

My proposal actualy allows us to generate field tiddlers for existing fields, independant of current handling. We can tag these to group them, we can provide a cutom view and document them.

I support nearly every aspect of your proposal as I understand it except the use of ▭ (or any other non-standard character) as the default or preferred prefix for field-config tiddlers. Why?

• If I want to edit a specific tiddler (especially a system/config tiddler), my first instinct is always to search for it. I understand that a hypothetical ▭ source tiddler would also come up if I searched for “source” (since it’s not a system tiddler). But this doesn’t really help me if I want to search (or perhaps more likely, filter for) all the field-config tiddlers, because I can’t type ▭ unless I happen to know its unicode value. I can copy-paste it, but only if I’m already looking at it, and copy-paste gets even more tedious on mobile.
• This means [prefix[▭]] — a very simple filter and, IMO, a reasonable category to want to filter for — is significantly more difficult to type than e.g. [prefix[$:/temp]]. This feels inconsistent with the principles of good TW design as seen in the core — not to mention close analogs like tags, where you modify the appearance of a tag pill by adding fields to the tag tiddler itself.

For that reason, I’d support @Springer’s “transparent” approach over one that requires an obscure prefix. I think it’s more internally consistent and also more intuitive from a user perspective. My only real concern is that it makes it difficult (or risky) to grab @Springer’s source field because I like her field configuration when I already have a source tiddler with its own non-field-config content.

@TW_Tones

Remember its your choice (or someone else who is giving you a solution)

You’re right, of course. There are a lot of plugins out there that aren’t for me (because they require a specific layout, or the code is hard to work with, or I don’t care for the design choices, or just because they haven’t been updated since 2020, etc.) but they’re for someone, and I think that’s great!

There are also a smaller number of plugins I liked conceptually enough to hack into a form that did work well for me, and some of these I’ve even repacked for my own use. This is a perfectly viable solution (though not, I suspect, a popular approach — it’s tedious!) and I’m glad that TW gives me the tools to do so, and grateful to the developers whose work I’ve frankensteined. But it does make it harder to get updates, and harder still to share solutions with other users. (“Well, you can do this with Shiraz, but I’ve actually added four parameters here and rewritten five of the constituent macros…”) So since you were thoughtful enough to solicit input prior to building the solution, I thought I’d try to campaign for a format that might not require too much tweaking.

[Springer]

@TW_Tones

Ok, Now create a shadow tiddler, you may not even have a “curated helper-interface…”. Currentlky that is not strait forward but we do build plugins to achive this.

As far as I understand, I (as an ordinary user) would never have a reason to want to create a shadow tiddler, except if I’m building a plugin-like solution (one where I’d need to establish a default suggestion while expecting some other end-user might prefer something else, even while needing my basic default to remain as a fallback if their variation is lost, or creates a mess and needs to be nixed). I don’t see where it would occur to anyone to create a shadow tiddler for their own non-developer purposes (though of course having backups of prior versions of this and that is always a good thing).

By contrast, I certainly want to be able to configure how fields work in my own wikis, and this interest emerges organically in working with TW as an end-user.

Since I can currently do so with ordinary TW5 skills (meaning, no javascript), I don’t think of a basic plugin in this area as enabling a new thing.

(Perhaps this is where your concerns, and your skills, are beyond mine! I’ve been thinking of offering a simple plugin, and it’s not going to involve any new javascript, and it would not bake in any expectations about fieldname prefixes (except perhaps in the fields-about-fields — see below). The goal would just be to make access to the deeper power of fields more convenient, and to to include some signpost-like documentation and useful templates.)

@TW_Tones

this is a key argument for field tiddlers to have a prefix

I think in another neighborhood of our conversation you were recommendation a prefix for the “fields about fields” — such as field-description or field_is_longtext (or whatever). That strikes me as a great convention with no downside, and the remaining challenge is just whether we can avoid relying on the English word “field” in that prefix — while still making the convention keyboard-accessible, and intuitive enough (hence my thought about leveraging §).

But if you mean that you imagine all (non-core) fields should have a prefix… … That would be a non-starter for me. In my ordinary work, I’m absolutely committed to fieldnames like “score” and “word-limit” and “DoB” and “user_id” — partly because I’m importing and exporting JSON data with other database systems with their own fieldname conventions, and partly because Shiraz tables work most conveniently with compact fieldnames. …

On the other hand, I do think distributed TiddlyWiki solutions should be careful to avoid barging into plausibly in-use fieldnames within the “customer” wikis that might adopt those plugins…, so purpose-specific (bibtex-) or developer-specific (PSaT?) prefixes are great in that respect. Maybe that’s all you meant?

[EDIT: I realize after a few moments… perhaps you meant not that the fieldnames themselves would have prefixes, but just that the tiddler (where info about the field lives) would have a prefix, so that the fieldname is a substring of that tiddler’s name. IMO, this creates some confusion, because if there can be a regular-old tiddler called bibtex-LCCN, it seems odd to expect that tiddler to be “divorced” from the meaning of that string as a fieldname… But I do see room for flexibility here!]

Great to be having these important conversations about where the opportunities and risks are!

[TW_Tones]

once again thanks @Springer and @etardiff for your feedback

I don’t have enough time for full answers just now but will reply more later

to be clear I propose a mechanism where by default field tiddlers are named exactly the same as the fieldname.

• however a global prefix can be set such as $:/fields/ which can be used to hide away the field definitions
• there will be a mechanism to override this prefix on a per tiddler basis allowing custom prefixes to be used for specific tiddlers

if neither of these are resolved, a tiddler does not exist, it uses the default and if no field definition tiddler is found it behaves as is.

• if a tiddler exists by the name of the fieldname it will not assume it is a field definition unless it contains something else like at least one field with the prefix field-

I think the above addresses all your concerns while maintaining the hack ability I am looking for.

• using unicode prefixes which is what I like is a red herring because it’s not part of the solution but a designer could choose it and it will work along side what other designers choose to use.

to find field tiddlers I intended to introduce filter operators like all[fields]

I will address your replies directly soon, next day or so.

thanks again.

[TW_Tones]

I cant get to involved here for now as I need to prepare to move home, from a house sit I have being
doing

@etardiff

no one is technically required to use a particular naming scheme. At the same time, shared tweaks and solutions are a cornerstone of the TW community

We can add to this “hackability” as another cornerstone.

My idea is that we have four posible “field tiddler” namespaces;

• local tiddler field provides a prefix name (optional eg comes in a plugins tiddlers, could be anything)
• a system-field-prefix by default $:/fields? (can be changed?)
• a standard-field-prefix by default (as a we agree eg § ) can be changed?
• No prefix at all just fieldname (Perhaps the default)

The above will be itterated for each field and find the first existing field tiddler from the top down and use that.

• later we may also use the same “cascade” to determin how to display a field, or edit from the view template.
• This resulting field tiddler namespace will be used in the editor to link to the field tiddler, and other features;
  • Description/tooltip
  • values filter
  • field-type…

New field tiddlers

However initialy at least most fieldnames will not have a field tiddler.

When creating or editing a tiddler, any field without a found “field tiddler” can be clicked on to create a field tiddler. I would suggest the default is just “fieldname”, however I also suggest the “field editor” have an option to change the “new field tiddler default” including; “no prefix” default, “standard prefix” and “system prefix” to allow easy creation of field tiddlers using these other namespaces.

• As configured above