Smarter Fields?

Developers
,
1

You know, all those things that right now end up being a bit “hacky”. Like, whether a field should be treated as multiline. Whether a field should only contain numbers, links, whatever. Obviously, the current fields editor would need a rewrite but that’s not a problem.

Sure. But you’d have no core support. All you’d be doing is creating a high-level mask over the current underlying implementation. What I’m proposing would need representation in the core tiddler json.

{
  "title": "my tiddler",
  "fields": [
    {
      "name": "my-field",
      "multiline": true/"yes",
      "kind": "number"/"date"/"plaintext"/"wikilink"/"ext-link",
      ...
    },
    {
      "name": "other-field",
      "multiline": true/false/"yes"/"no",
      "kind": "number"/"date"/"plaintext"/"wikilink"/"ext-link",
      ...
    },
    etc...
  ]
  ...
}
3 Likes
Maintaining one word titles as links?
2

In 2021 I did create a “system field” spec for the .tid file format. How could system-fields look like with 5.2.x · Jermolene/TiddlyWiki5 · Discussion #5805 · GitHub

The main problem at the end has been, that “fields” would have been “mini tiddlers”, which is a bit against the TW philosophy, where the tiddler should be the “smallest” piece of information.

Non the less, it would have been super flexible.

The final version has been this: How could system-fields look like with 5.2.x · Jermolene/TiddlyWiki5 · Discussion #5805 · GitHub

1 Like
3

Perhaps we could move the meta-field info into a separate tiddler and mark the original host tiddler with a hint that the extra data can be found there?

{
  "name": "my-tiddler"
  "fields": [
    "meta": "$:/my-tiddler/meta-data", <-- call it anything you like
    "caption": "my-caption",
    ...
  ]
...
}

Of course, we could make the title of the metadata tiddler a prescribed format: "$:/metadata-for/my-tiddler" and use it, if found, and fall back to regular TW5 parsing if it doesn’t exist.

{
  "title": "$:/metadata-for/my-tiddler",
  "fields": [
    {
      "name": "my-field",
      "multiline": true/"yes",
      "kind": "number"/"date"/"plaintext"/"wikilink"/"ext-link",
      ...
    },
    {
      "name": "caption",
      "multiline": false,
      "kind": "wikitext",
      ...
    },
  ]
  ...
}

But even that seems hacky.

4

This would go a long way to solving something I asked about more than a year ago: Tiddlers with JS-prototype tiddlers.

5

I will revisit this later but I think it may be resonable to have the option of “field tiddlers” just as we do “tag tiddlers”.

I would love to learn more about your idea here.

I will share more of my own work on this later which is similar to what some of you are suggesting.

6

It was no more than a brainfart with cobbled examples. You’d go further looking at @Scott_Sauyet’s idea (see above) and much further still with @pmario’s proposal. In fact, Mario went as far as documenting what might be fed to the parser. Cool stuff.

But, since you asked, take a look at this (I’m abbreviating the json referenced above)

[
  {
    "title":"my-tiddler"
    "fields": [
      {
        "meta":true, <-- true means use the prescribed format $:/metadata-for/my-tiddler
        "caption": "My Caption"
        ...

So, the implication is, the field data for my-tiddler is deferred to $:/metadata-for/my-tiddler because the meta field is marked true. I’m just saying that’s a possible implementation.

Now that you have your fields deferred to a meta tiddler, you can start the next debate: which caption wins?

  1. The meta tiddler is a prototype so the caption in my-tiddler wins.
  2. The meta tiddler is a cascade so the caption/last link in the chain wins (arguably)

#2 also implies…

[
  {
    "title":"$:/metadata-for/my-tiddler"
    "fields": [
      {
        "meta":true, <-- true in a meta tiddler means we're chaining meta tiddlers
        ...
  },
  {
    "title":"$:/metadata-for/$:/metadata-for/my-tiddler"
    "fields": [
      ...

Which I think is a potential nightmare. Much prefer #1, a single prototype. But what do I know, you guys may have other ideas.

7

Numbering added

I absolutely prefer #1. Of course this aligns with the idea I linked to, but more than that, it feels ever so much more flexible. Multiple tiddlers could point to the same parent and inherit their (non-overridden) fields from the same place.

1 Like
8

Thinking further…

If we fostered the prescribed format, $:/metdata-for/X, we don’t actually need the hint "meta":true. If the metadata-for tiddler is found, use it. Unless the search is costly and providing the hint negates the cost…

Is there no chance this might be revived?

1 Like