[Proposal] Updating field handling functionality in TiddlyWiki

Developers
, ,
#44

With apologies for some overlap between our topics, I also have been wrestling with this NAMESPACE question:

Since some of what I’ve been working on has a different emphasi-, I started another (but compatible) thread … mostly focused on the GUI I’ve developed for opening up fields as nodes where interesting things happen.

But YES, there are pros and cons to the “direct” approach of just making a tiddler called bibtex-title, and having that be the home for all the “meta” stuff about that field…

#45

Yes, I replied to Proposal: render fieldnames as links, and see what's possible with fieldname nodes! - #2 by TW_Tones and it contributes to this conversation.

Tiddlers with the name of a fieldname could have within it a set of fields named with the field- prefix like your field-description, allowing the tiddler to also be used for other purposes. Although a tool may be needed to be used to extract for reuse in another wiki.

An example may be domain, which can be a tag that defines what part of your life it related to eg work, personal, play, family, friends. the domain field can have one (or more of these domain names in its value). It would be a tag, a field definition, a source of field values and documentation about what a domain is.

I think this is the most obviouse next step

What ever we do in the future we do need to choose a default, and for the experimentation I am tempted to start with either direct fieldname or the aformentioned ▭ fieldname.

  • Can only be (easily) created via the new fieldname process
  • makes sence to start with an extewndable cascade for this.
    • Allowing us to change the default
    • Allowing the cascade to address fields via wildcards with a prefix or suffix seperatly.
      • Eg all -link fields can be handled one way and we dont need a definition for every field.

I also think it safe to aggree that all field related fieldnames be prefixes field- or ▭ , in part because we can then use a wild card prefix to list them all.

  • if using ▭ we can make a tool to access the symbol (and others as they arrise)
#46

That actually sounds great to me! (EDIT: Just to be clear: There can still be some fields, such as “notes” that are put to good common use across field tiddlers and other tiddlers. I see your proposal as recommending a prefix for the kinds of fields that are specific to fields (like field_holds_longtext or field_data_type). Naturally the fieldname tiddler gets a modifier and modified field, and can take notes, tags, etc., as desired.)

(About the alternative other than field-: I wonder whether you see something other than a weird box for the special prefix you’re suggestion. Maybe it’s a platform or browser thing. The ▭ just looks like a blooper rectangle on my screen.)

Plain old “naked” fieldnames don’t actually seem to have much risk to me beyond being inconvenient in some “curated” enviroments… And for that matter it’s not too hard to add optional filters to my sidebar lists and search results, if I don’t want to see fieldname tiddlers there.

But even if we were to see strong reasons for a special prefix, I am still absolutely tempted to start the design work around the the direct (“naked” name) solution, because it’s so much easier to get proof-of-concept “intertwingularity” this way.

Once the power of the approach is demonstrated, then if we really want the fieldnames tucked into a special string, it would then be straightforward to build a few custom functions and cascade conditions (to get the “real” fieldname string into/out of the chosen prefix/suffix namestring padding)… We can cross that bridge when we come to it, knowing what kind of GUI and data structure feels right.

#47

I partialy agree here, but building a cascade from the beginning to determin the fieldname tiddler, even if only direct intialy, we allow others solutions to leverage it, and we are not opinionated.

There is another reason to develop a cascade solution, that is currently we dont have a way to say how to display a field, but we do have one to edit a field (see Field Editor cascade). By building a cascade for that we can lookup how to display a given fieldname such as by looking in the “fieldname tiddlers” field-viewTemplate field, also optional field-editTemplate field.

  • That is this approach starts by building the infrustructure and setting some useful defaults.

I have just being experimenting with a cascade to determin the field definition tiddler title and the standard cascades dont do what I wish. It always results in a transclusion. Although I stand by the field-viewTemplate, field-editTemplate cascade idea.

  • I will present a solution Post haste :nerd_face:
1 Like
#48

It does to me too, though maybe that wont be as big an issue in context of being used in TW?

An alternate unicode character perhaps:

⽥

It has a nice symmetry to it, looks like a table (not unlike how two field/value pairs would be, conceptually) with tails that imply more

Oh, and it’s unicode name (this is how I found it) has the word “FIELD” in it (one of only two in my slightly-outdated unicode reference. The other being field hockey. The existing suggestion is the generic “WHITE RECTANGLE” character)
⽥ 2F65 KANGXI RADICAL FIELD
:field_hockey: 1F3D1 FIELD HOCKEY STICK AND BALL
▭ 25AD WHITE RECTANGLE

(that said, I definitely have a preference to not requiring special prefixes, but having one standardised (or conventionalised) prefix definitely has it’s benefits. Part of me thinks it should just be X- as per old email header conventions. But apart from history and easy of typing, there isn’t much to it, and a more semantically valid unicode character makes a lot more sense)

#49

I would prefer to use ⽥ for a table tiddler, something I am working on.

  • It risks being close to table, row/column and other ideas that are close to the concept of field, but not a field.
  • I remain open to suggestions.

To be sure we are seeing the same thing
2025-08-26_13-40-09

  • I have looked for ages, and this seems right to me, but it is all in the air, in fact $:/fields/ maybe the most common outcome.
  • Keep in mind it will always be alongside a defined fieldname eg ▭ description ▭ caption 

### A global function to find currentField-definition 
* using the currentField variable used in the field editor and elsewhere.
* tagged $:/tags/Global

\function currentField-definition() [subfilter{!!currentField-definition-filter}!is[blank]] [subfilter{$:/config/fields/currentField-definition}] []

* Use the above and it can be overidden in any tiddler
* It will acess the filter in `$:/config/fields/currentField-definition` 
* or default to fieldname.

Note that whilst $:/config/fields/currentField-definition if used becomes global it can be a quite sophisticated filter such as differentating between system and standard fields etc...

[field-handling-definition.json|attachment](upload://c9ONwmeZbJB8cMNSgaTe4XiZ2aB.json) (806 Bytes)

Please suggest and edit if nessasary but if you use this "we will be on the same page/tiddler"
#50

ah more than obvious enough reason to not use it here then!

Perhaps multiple horizontal without the vertical divider - two different scales (I found the first first, but prefer the latter for ease of visibility):
▤ 25A4 SQUARE WITH HORIZONTAL FILL
⊟ 229F SQUARED MINUS

Then tables could even be the crosshatch versions of the same for within-unicode consistency?
▦ 25A6 SQUARE WITH ORTHOGONAL CROSSHATCH FILL
⊞ 229E SQUARED PLUS

Another thought, from a completely different visual thinking - this looks like the : that seperates the name and value of a field (there are many ‘colon’ variations, but most aren’t visually useful)
⍠ 2360 APL FUNCTIONAL SYMBOL QUAD COLON
#51

It is possible to waste hours with this kind of thing.

  • I have used ChatGPT to simplify this

I just thought we don’t need to have only one character so these are possible

  • ASCII [█] or [-] or [- - -] or [ - ] or [_] or [~] or [ ~ ] or [~]
  • Unicode “□■□ description” or [⸺] using a 2em dash

It is possible to use svg but not in our tiddler titles, it could be in our icon

  • The icon will only be visible where displayed and not visible within the listing of such tiddlers.
#52

I read this thread in a hurry in the flurry of catching up after a two-week vacation. Now that @Springer brought it back to my attention, I see great promise here.

I wanted to offer one possibility that I don’t think was mentioned above: should we have an entirely different type of tiddler for a field definition? As in the type field having a new option of Field Definition (text/vnd.tiddlywiki-fielddef) in the type dropdown.

This seems to be the top level of tiddler-handling differentiation, and, as it strikes me that we’d quite possibly want the editing and viewing interfaces optimized for such tiddlers, this would probably be the simplest mechanism to do that. It would also gives us an easy way to search for them.

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.

#53

I will reply tomorrow with some background on this. thanks for contributing

#54

The type field is intended to be use like IANA mime-type. So creating new ones in an uncoordinated way, will make things more complex in the future.

There is an issue form 2014 at GH: Introduce vocabulary parameter to wikitext content type · Issue #345 · TiddlyWiki/TiddlyWiki5 · GitHub that you should read in its entirety. There even is a PR as you can see at the comment from buggyj.

#55

Understood, but thy are like IANA media types, right? Or have we gone through a formal registration process for

  • text/vnd-tiddlywiki
  • text/vnd-tiddlywiki-multiple
  • application/x-tiddler-dictionary

? I was simply suggesting that it might behoove us to add one more, chiefly as a way to give these field definitions their own fairly different UI than plain tiddlers, CSS files, PNG images, etc. This was a spur-of-the-moment proposal, and I certainly haven’t thought through the implications.

I have now read that thread, which I hadn’t seen before, and glanced through the changes @buggyj suggested. I didn’t find the actual PR, though I didn’t look hard. Was it merged? I certainly would not object if this functionality used a vocab parameter to vnd.tiddlywiki rather than an entirely new type. (I have no idea if the registration process includes descriptions of all such parameters.)

But more generally, I couldn’t tell from your message whether you were trying to express an objection to my suggestion, or just provide some background on related discussions. “In an uncoordinated way” makes me think it was an objection, but I was thinking that this would be an upgrade to the core, perhaps for 5.4.0, perhaps even later. I would assume we would have time to coordinate this, and if we do register our internal MIME-types, we would have time for that.

But again, this was a passing thought, not a deeply considered suggestion. It may be unusable for all sorts of reasons.

#56

The preview TW is at: http://tw5vocab.tiddlyspot.com/
The repo is at: GitHub - buggyj/TiddlyWiki5 at remotes/origin/vocabs

It’s from a TW beta version from 2014

It was an objection about a new type.

I think the discussion Proposal: render fieldnames as links … and here IMO all will “hit the same road-block” as my thought experiment: How could system-fields look like with …. I think it’s exactly the same, from an “implementation standpoint”.

TLDR; Jeremy’s objections Fields with meta data are tiddlers.

We did not officially register them, which we probably should. But I think that’s a rather “tedious” process.

I do not really know, why @jeremyruston did create text/vnd.tiddlywiki-multiple instead of introducing a text/vnd.tiddlywiki; vocab=multiple type, which probably would have been more in line with his proposal: Introduce vocabulary parameter to wikitext content type

But I think it is not too late.

#57

Hm, I propose this one:

§

As far as I know TiddlyWiki makes no formal use of it yet.

The § character means “section” and has a nice semantic relationship to the idea of a field as a sectioned-off element of a tiddler.

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 □.

#58

I don’t yet clearly understand what the objection is (or what the objection is directed against). Happy to hear from @jeremyruston … Fields can be mere strings, just like tags can be mere strings. Nothing about allowing for field-tiddler development prevents anyone from continuing to use fieldnames as “flat” strings.

But nothing prevents a fieldname from becoming the name of a tiddler, which is home to whatever content — including fields — we find appropriate. (And some likely common patterns can shape best-practice discussions for what kinds of attributes we are likely to assign to fields as such, including whether to converge on some naming practices…)

In a way, preventing such dimensional power for fields would be resisting the TiddlyWiki philosophy (everything is — or can be — a tiddler). But I suspect I’m not understanding the context of the objection well.

#59

Alt-21 on Windows.

It’s more complex on Linux, because of the many flavors and various keyboard designs, but it’s available with at most a few keypresses on any of them.

1 Like
#60

@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

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;

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.
#61

I tend to agree. I do see value in signposting whether (and how) a given field name is already used by core. But outside a few instances in which “misusing” a field may have unintended side effects (like the class field, if you happen to have a CSS class that matches whatever content you put in the field… guess how I found that one out?) I don’t think there’s much harm in reusing fields like name, source, or even subtitle for other purposes. So I support your conclusion here:

Re: the namespace issue…

I know you already know my thoughts on using unicode characters in config tiddler titles (to wit: please don’t), but I read your response in another thread right after I read this one and couldn’t help but note some irony…

Why make accessing these tiddlers intentionally difficult? (Let’s set aside the issue of whether you find it substantially more difficult; I, at least, would find it frustrating.) Don’t we all have the god-given right to screw up our own wikis? :stuck_out_tongue:

#62

I can imagine one kind of fieldname solution that tucks much of its mechanics “under the hood” so that things are handled according to a careful system.

I don’t imagine that I would myself prefer that kind of solution. I prefer a transparent approach: “Look, here are some tiddlers whose names are fieldnames, and here’s how adding fields to those tiddlers opens up possibilities!”

Some visual distinctions, and some hierarchy of obviousness, can still be wise. I’m thinking of how system tiddlers look different and don’t appear in searches until you use the advanced-search tab. But if someone told me that I could only create a system tiddler by going through a curated helper-interface… and that this was for my own good … :grimacing: I think the power of fieldname tiddlers (and their fields) is comparable. We want to hammer out reasonable levels of protection against accidental mangling, and reasonable “handrails” for enabling people to move around efficiently. But not much more than that.

I think this whole process (of reflection on the power of fields) may lead us toward some basic tweaks that reduce the risk of this kind of problem.

If choosing a fieldname (in the edit-fields interface) means choosing something within a space that easily triggers some smart css (following attributes of fields), then it would be easy to add gentle-warning formatting/icons for “special” fieldnames.

1 Like
#63

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

Also we already have specific methods to create tiddlers, use the new tiddler button, follow a link as well as with tags (add to a tiddler then click on the tag pill) sure you can create a tiddler of the same name but it will not be a tag until used as a tag.

Note: Thanks @Springer and @etardiff for you contribution and rigorous debate :nerd_face:

Keep in mind my proposal keeps the fields visable, searchable , editable etc… but it also allows us to quickly identify them as would $:/fields/ prefixes

  • My point is we implement a method where you can choose both globaly or fields within for specific tiddlers, or class of tiddlers. I am not proposing the reduction of any feedoms I am expanding them.
  • I think it is safe fore us to prototype this and you can try it and I expect see my proposal is not proscriptive.

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.

  • Not very difficult :nerd_face:
    • We could detect its a field and offer an option even if missing
  • In part the reason is so as to ensure the “handling clicks in” when such fields are created. For example in my current model one can determin the fields namespace by including a field, defining it, in every tiddler. This allows the link, the open to edit field and subsequent edit and view templating to be aware of these custom field namespaces with no further configuration.
    • Enabling a set of field definitions scoped for a given solution or plugin
    • thus Supporting the reuse of fields within a scope
  • If I just created a new field definition eg $:/plugin/PSaT/concactDB/fields/fieldname or &fieldname, without going through a supported method, there would be need for hidden information to make it work. I am only suggesting encoraging the user.

also

@etardiff
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.

For example the aformentioned class field

  • class field “This field has a default use and should be avoided” It allows the naming of one or more class names, which will be alpplied to the tiddler on which it has a value.
    • give examples
    • propose use anyname-class or function-class etc… for custom class fields.

If you are still not persuaded;

  • Remember its your choice (or someone else who is giving you a solution)
  • Give me a specific example?