How could system-fields look like with 5.4.x

[pmario]

Inspired by: #5804

Latest example: #5805 (comment)

We do have system-tiddlers that start with $:/ which makes them almost invisible for ordinary users. The same thing could be true for system-fields ... BUT ... There needs to be an additional property for those fields.

We always had problems with some special system-fields: created, modified, tags .. those fields do have a "special handling" in the core. .. They use "setters" and "getters" to convert them on the fly. Such a behaviour would be nice to have for "user fields" too.

Proposed system-fields spec

(edited 18.6. changed $:/ to #/ to reduce confusion. see: #5805 (comment))

• They start with #/
  • The : char may be problematic. see: [BUG] Tiddlers with multi-line fields can be incorrectly exported as .tid files #5809 ... (22.6) removed it from all posts
• They are hidden from default search
• They are hidden in the EditTemplate
  • There should be a small unobtrusive indicator, that "hidden fields" exist
• They MUST have an <type> snippet as the first element iin the namespace: #/<type>/ eg: #/date/
• They do have an <author> snippet in the namespace .. eg: #/date/<author>/
• If they are used in plugins the do have <plugin> snippet in the name .. eg: #/date/wikilabs/<plugin>/xxx
• If they are connected to a visible user filed they may look like #/user/<type>/<name of the field>
  • user-fields, that have a related system-field should have an unobtrusive marker
• If they need a multiline editor #/user/multiline/<name of field> or #/multiline/<author>/myDescription. So the myDescription field would automatically show a multi line editor.

Possible Types

• user ... the field will create a visible "user-field" (22.6 changed)
• _ ... user ... a convenience type, to create shorter names (22.6 changed)
• string ... string (22.6 changed)
• date ... similar to modified
• tag ... similar to the tags field
• list ... similar to the list field
• type ... MIME type .. So an automatic "dropdown" can be shown (22.6 replaced by mime)
• color ... A color selector can be shown
• mime ... A field that can be defined by an official mime-type (22.6 new) see: How could system-fields look like with 5.4.x #5805 (comment)
• multiline ... shows a multiline edit field .. (22.6 replaced by mime)
• relations ... I don't know how this will look like .. But may be multiline with a key: value pair ...
• json ... A multiline field, that contains a JSON structure. ... IMO this may be nestable (22.6 replaced by mime)

(remark 22.6) With the MIME-type idea, it may be possible to reduce or get rid of this configurations. -- Will need to be explored

Needed

• IMO it's just a new convention, that will allow us to improve field flexibility
• There needs to be a possibility to define such "system-fields" globally.
• There needs to be a UI that will allow us to find all system-fields, since they are invisible for the standard search
• AdvancedSearch probably needs a new tab .. may be

[Jermolene]

Hi @pmario

• I'm concerned that making field names look like system tiddler titles will add a lot of unnecessary confusion. Right now if I see $:/foo/bar it is fairly safe to assume that it is a tiddler title. It would be a shame to add ambiguity. So I think it would be better to use a different prefix and separator. Perhaps underscores to match the existing _canonical_uri field
• I don't understand why it is useful to have fields that are hidden from end users. If a plugin needs to add metadata to a user-created tiddler then I'd normally use a separate configuration tiddler
• Having fields that a user can't see would seem to invite confusion. For example, if updating such fields also updates the "modified" field then users will wonder why tiddlers with no apparent changes have moved to the top of the "Recent tab". But, conversely, if we don't update the "modified" field then we'd have introduced the phenomenon of tiddlers that change without them moving in the "Recent" tab

Overall, I would take these proposals as interesting starting points for establishing conventions for the use of field names, but I don't think we're ready to bake those conventions into the core

[kookma]

I am very much for simple and more understandable field names! I don't think TW needs to have such complexity in filed naming etc. So I highly support Jeremy with his above explanation!

Please note: field names normally used for scripting, transclusion (e.g mostly [not always] of programming use case) so it would suffice to have filed name in lowercase and I think few usecases needs special chars, upper case, etc.

[pmario]

I don't understand why it is useful to have fields that are hidden from end users. If a plugin needs to add metadata to a user-created tiddler then I'd normally use a separate configuration tiddler

modified, created, creator, modifier are hidden and nobody complains or is confused about that.

Overall, I would take these proposals as interesting starting points for establishing conventions for the use of field names, but I don't think we're ready to bake those conventions into the core

That's why it's under "Discussion" and not an issue.

[pmario]

@Jermolene wrote

I'm concerned that making field names look like system tiddler titles will add a lot of unnecessary confusion. Right now if I see $:/foo/bar it is fairly safe to assume that it is a tiddler title. It would be a shame to add ambiguity. So I think it would be better to use a different prefix and separator. Perhaps underscores to match the existing _canonical_uri field

That's fair. ... IMO underscores are not really good separators for a namespace.

What about §:/ or #:/ as a prefix §:/foo/bar -- $:/foo/bar -- #:/foo/bar ... I think the later has the biggest visual difference

[pmario]

The field named: color automatically gets a color-picker ... Why does the field: myColour get no color-picker?

IMO #/user/color/myColour value green would easily solve the problem. green would be the default colour, if the user would create the field: myColour ... The system field would be invisible and the myColour field would get a clickable visual hint, that it has a configuration field.

With the hint, I think there wouldn't be any confusion

[pmario]

Possible workflow for a "multiline input area"

• I do create a field name: #/user/multiline/teaser value:rows: 4
• Click the [add]-button
• A field named: teaser will be automatically created and a text-editor with 4 lines will be shown.

I think that would be cool!

[pmario]

It would be cool if #/user/multiline/teaser would support all parameters from https://tiddlywiki.com/#EditTextWidget

If system-field parameters look like widget parameters, they should be easy to write and parse.

A non working .tid could look like so:

title: my tiddler
#/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                     <- end-marker
some text

Thinking a bit further. What if the multiline field would look like this:

#/user/multiline/teaser: rows="4" minHeight="3em" tiddler="somewhere else"

Would this have use-case?! Would the "relink plugin" be able to handle this? Edit: 2022-12-05 (No tiddlers should be "self contained")

[pmario]

@Jermolene wrote

Having fields that a user can't see would seem to invite confusion. For example, if updating such fields also updates the "modified" field then users will wonder why tiddlers with no apparent changes have moved to the top of the "Recent tab". But, conversely, if we don't update the "modified" field then we'd have introduced the phenomenon of tiddlers that change without them moving in the "Recent" tab

If I change a field something, which is dynamically updated, but not shown in any UI context it will also change the modified field. ... I haven't seen any complains about fields that work that way. .. So I think it won't be a problem with #/system-fields

[pmario]

@Jermolene What do you think about multiline fields like this:

title: my tiddler
#/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                 <- end-marker
some text

[pmario]

From the system-field we know, that teaser is multiline. The end-marker can a dynamic string eg: -=-=-=-=-
I think parsing this should be straight forward.

[AnthonyMuscio]

Mario,

Would it be too much to actually name the text field text: and allow it to be followed by a mime type or other format eg

title: my tiddler
tags: a b c
text:text/vnd.tiddlywiki
Multiline text
data:application/x-tiddler-dictionary
data dictionary text?
journal-date:date-time

The actual format or mime types need not be stored in the tiddler, only obtained before exporting. Keeping in mind this will be different in the JSON store.

The idea is the type becomes associated with the field not the tiddler as a whole, which really only means the text field anyway.

[pmario]

That's a very interesting idea. I'll follow it

[AnthonyMuscio]

All,

I would like to support what Mario is trying to achieve here there are two key reasons we need some change which is appropriate at the same time as the field namespace expands.

Another is the possibility that the JSON tiddler structure that allows these field extensions also opens up the use of editing the current tiddlers and their fields through the view template without the old focus problem. I believe this will stimulate the development of interactive forms and thus the demand for fields to have better handling, ie become first class citizens (like tags)

• Currently there is no open hacks to duplicate the behaviour of created, modified and color fields (lets call these magic fields), ie provide edit and display of fields with a known types.
• I would extend Mario's ideas to have field definition tiddlers (as we can have tag tiddlers) and for fields to be assigned field-types (custom AND/OR mime type)
• Until the fields editor can detect and handle multi-line fields there is a reason to hide a field from the editor (even if another field editor is reintroduced via $:/tags/EditTemplate)
• If the edit template allowed fields to be arranged, sorted, be given definitions , hidden etc.. the edit template could respond better to the use of custom fields. However other than multi-line fields I believe the edit view should remain the designers opportunity to edit anything, where form handling from the view template should be the designers responsibility and full control.
• There is value in being able to set a global and tiddler mode to alter the way thwe user interacts with the wiki eg edit, view and Update tiddler modes, where update allows a form to be used to edit the tiddler and makes use of field definitions and field types to provide the appropriate field editor.
• Rename local-viewtemplate.json.txt to import my local-view template that has a multi-line field on tiddlers. Add the field local-viewtemplate on a tiddler to see it. Then add content to display on view template.

Mario,

Perhaps rather than defining the field as a system field using a name prefix perhaps we externalise it to a tiddler or data tiddler. This may be necessary any what to support field definition and field types. We can then flag the field definition tiddler as system or hide etc...

I have done this many times so can demonstrate this in more detail. It keeps the solution much more open. Separate field types allows a set of generic display and edit features to be developed for reuse in many field definitions. eg one field type for date applied to many date fields. Field definitions and types would allow the sharing of these for import without insisting on a wiki edition that supports a given field. Perhaps ultimately some field definitions would move to the core (or replace the existing magic fields) . Such definitions and field types can be cloned by the designer to extend or customise new fields.

I think this solution also more closely resembles other systems and is not yet another TiddlyWiki quirky implementation, of a common or garden element such as fields.

Regards
Tony

[pmario]

I would extend Mario's ideas to have field definition tiddlers (as we can have tag tiddlers) and for fields to be assigned field-types (custom AND/OR mime type)

I want tiddlers to be "self contained". So if possible, the info shouldn't be split into 2 tiddlers, because that causes a sync problem

[pmario]

If the edit template allowed fields to be arranged, sorted, be given definitions , hidden etc.. the edit template could respond better to the use of custom fields. However other than multi-line fields I believe the edit view should remain the designers opportunity to edit anything, where form handling from the view template should be the designers responsibility and full control.

Having better control of the field types, will allow us to create an EditTemplate, that looks like a ViewTemplate. ... So we can go away with all the ViewTemplates hacks, that only cause problems. .. If I need to edit something I should use an EditTemplate...
This EditTemplate can be adjusted on a per tiddler basis.

[pmario]

Perhaps rather than defining the field as a system field using a name prefix perhaps we externalise it to a tiddler or data tiddler. This may be necessary any what to support field definition and field types. We can then flag the field definition tiddler as system or hide etc...

As I wrote. I'd like to have self-contained tiddlers including all the meta-data

[AnthonyMuscio]

Mario,

I think that is a good approach yet a field definition is something that sensibly applies wiki wide. An example is the color field, it is not defined in the tiddler but elsewhere in the wiki. What would be ideal is a fall back to a simple editor as we currently do, if the definition is not present, or at least a single or multi-line edit. If both an assignable mime or format type exists use it. This allows extensibility and fine tuning at the same time.

A simple example of extending field definitions and types beyond that which we would store in each tiddler may be a field definition whose value can be selected as a result of a filter or even a MRU most recently used values list.

Tony

[AnthonyMuscio]

The exception may be for multi-line fields that can be appropriately defined with A type or mime type in the field, ensuring transferability.

My concern would be having the metadata always in a field within a tiddler giving rise to redundant information through out the wiki. A compromise with a fall back would be the best method. Perhaps with an export method that includes the metadata if desired.

Tony

[pmario]

New possible .tid format

title: my tiddler
#/user/multiline/teaser: rows="4" minHeight="3em"
tags: a b c 
teaser: MIME-TYPE  |  -=-=-=-=-                     <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                     <- end-marker

• Since mime-type naming specification doesn't allow the "pipe" | character in the name, it is safe to use it as a separator for the "end-marker"
• Since the : character is problematic in field names I did remove it from all posts

[AnthonyMuscio]

Mario,

Some creative speculation.

It seems however we come to this type of approach, it seems having a "nonmeclature" that allows us to hide additional content in the tiddler for a given tiddler/fieldname would make sense. Basically an escape sequence and within the escaped information we can add something such as a mime type or format tiddler (Containing info about how to display/edit, export etc..)

The idea is if we have to look at modifying the rules around tiddlers lets do so with a view to a generic feature, then build a specific instance of using that (field types).

I suppose what I am proposing is a generic solution to adding additional information to a field defined in a tiddler, and saved in the tiddler that although saved with the tiddler is ignored unless a process exists to handle the content. then one instance of this use could be a "mime-type:text/vnd.tiddlywiki" or "field-type:typename". This possibly becomes easier with tiddlers stored as JSON?

I suppose we could also say the new tiddler format permits the inclusion of metadata against any field. A special field for whole of tiddler metadata would be nice as well. Arguably a tiddler could contain its own metadata naming the default export template or format it can save as. ie tiddlers could be designed to export as other file formats and types.

With the above in mind, could it be as simple as using comments within the content of the field? , then when transcluding or editing don't show the comments?

Or
fieldname<!-- mime-type:mime-type:text/vnd.tiddlywik export:command-file.cmd -->: value

Tony

[AnthonyMuscio]

In the above example if we can extract the mime-type from fieldname, or present it as a virtual field/value, all the better.

[AnthonyMuscio]

As I also suggested before but for clarity re local global/default.

Lets say I had a field called "data:. I may wish to create a tiddler containing something like
data:<!-- mime-type:application/json --> however I want to be able to define the "data" field in my wiki as having the mime-type:application/json basically a global field definition is possible, but a local override is also possible. So the data field may be application/json but in a specific tiddler it may be text/plain

Tony

[pmario]

A new try with mime-types and different elements.

#/mime/#icon: width="100px;" height="50px;"
#/icon: image/png | === end-image                                  <- This is a system-field
"data:image/png;base64,iVBORw0KGgoAA....."
=== end-image
title: my tiddler
#/_/mime/teaser: rows="4" minHeight="3em"
#/_/mime/wikitext: rows="10" minHeight="3em"
tags: a b c 
teaser: text/plain  | -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                     <- end-marker
wikitext: text/vnd.tiddlywiki  | -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3
-=-=-=-=-                                                                 <- end-marker
#/_/mime/date: <info for a date-picker to specify>        <- jCal format https://datatracker.ietf.org/doc/html/rfc7265#section-3.6.5
date: application/calendar+json | -=-=-=-=-
["dtstart", {}, "date-time", "2012-10-17T12:00:00"],
["dtstamp", {}, "date-time", "2012-10-17T12:00:00Z"],
["dtend",
    { "tzid": "Europe/Berlin" },
    "date-time",
    "2011-10-17T13:00:00"
]
-=-=-=-=-

some text

[AnthonyMuscio]

Mario et al,

Ok this is "out of left field".

Another approach to "system fieldnames" and "tiddler titles for that matter" is the use of unicode. If a field is named with a Unicode character or an alternate Alphanumeric set, without help, people can not enter the name in the search box, so they remain hidden from the basic search however with a unicode font that displays the name it remains readable.

To support such a method we could do with an in wiki Unicode keyboard.

Of course we need to consider the implications of this, but we also need to take account of this possibility with the new expanded field naming.

Perhaps we could have a single Unicode character acting as a Synonym for $:/ when used as a prefix to a field OR tiddler name?
Eg the fullwidth "Ｓ" or ℐ for fields.

I have played extensively with Unicode, and tiddlywiki is quite accommodating with tiddler titles but currently not with fieldnames.

Tony

[simonbaird]

On the topic of how to encode multi-line values, could we use an existing standard instead inventing our own? How about YAML?

[saqimtiaz]

YAML and the use of it as frontmatter in markdown has been on my mind for multiline support in .tid files. I haven't had the chance to look into how well it handles longer context though.

[pmario]

console.log(require('yaml').stringify({"text":"Some content", "title":"MyTiddler", "a multi-line field":"this\nthat"}))

If I paste this into the browser console, I get "require not defined" ...

[pmario]

text: Some content
title: MyTiddler
a multi-line field: |-
  this
  that

That's nice, but there isn't enough information for the UI to know how to display the input area in the EditTemplate.
There isn't any information about the render-type. .. Should it be wikitext or plain-text?

IMO these elements need to be user-defineable

TW doesn't have a YAML parser atm. We would need to bind a 3rd party dependency into the core.

---

The following code has all the info to tells the parser and the UI how to create an input area for the field. The only new thing is that I need to tell the parser where the text-block ends. eg: -=-=-=-=-

#/_/mime/wikitext: rows="10" minHeight="3em" _endString="-=-=-=-=-"
wikitext: text/vnd.tiddlywiki 
line 1
line 2
line 3
-=-=-=-=- 

[pmario]

The code may also look like this. Depending on what's easier to implement.

#/_/mime/wikitext: rows="10" minHeight="3em" 
wikitext: text/vnd.tiddlywiki | -=-=-=-=-
line 1
line 2
line 3
-=-=-=-=- 

[ght]

YAML and the use of it as frontmatter in markdown has been on my mind for multiline support in .tid files.

TW doesn't have a YAML parser atm. We would need to bind a 3rd party dependency into the core.

I strongly urge you to consider alternatives first, YAML has a bunch of problems, see https://noyaml.com/.

[pmario]

On the topic of how to encode multi-line values, could we use an existing standard instead inventing our own? How about YAML?

The only thing which is new in my proposal is the "start" and the "end" definition of a multiline field. Everything else is already part of the TW core parser primitives. ..

[simonbaird]

I agree the the overhead of adding js-yaml to the core is probably a blocker for using YAML. But I just want to mention the idea of using something standards based instead of "special for TiddlyWiki" in case it leads anywhere.

One more comment: it seems weird to include the width and height of a text area in the tid file. Could there be some other way to associate a specific UI template with particular field name?

[pmario]

One more comment: it seems weird to include the width and height of a text area in the tid file. Could there be some other way to associate a specific UI template with particular field name?

If it should be "self-contained" the info has to be part of the tiddler. ... On the other hand, there may be the need for "global" field definitions .. I didn't think about that in detail yet, but there may be 1 "meta" tiddler per global field

The disadvantage with 2 tiddlers that belong together and don't work without each other is all kind of syncing problems. I would like to avoid that

[AnthonyMuscio]

Mario,

I understand your desire to make tiddlers stand alone, however this is only necessary in some cases. An example may be my tiddlers may be todo tiddlers used inside Projectify,, now I may add a sunset-date field to a tiddler - lets imagine now there is a "field tiddler" called "sunset-date" and a field-type tiddler called date. If I drag and drop this tiddler to my other wiki I may not need the field and field type tiddlers because they are already their.

My experience tells me that we could call a field almost anything, but the number of field-type tiddlers can somewhat be finite. I envisage us collecting a set of field-type tiddlers into a plugin and sharing them so if you drag tiddlers with custom fields you can then assign the desired type to each field according to the needs in the destination.

Alternatively we can make a special bundler plugin that takes the tiddlers defined in a filter and sources all their field definitions and field-types in use and adds them to the package.

I can see that there may be a $:/field/description tiddler which has a field-type field of text-80, for which their is a tiddler "$:/field-type/text-80", which indicates its visible in the edit mode (not hiddent visibility), and that is uses {{!!fieldname}} to display in view and
<$edit-text field="description" size=80 placeholder="provide description"/> to edit.

So any field will try and find its field tiddler using the default naming standard (prefix $:/field/) UNLESS an alternate is named in the tiddlers hidden area, or as proposed there is a mime type.

I will try and deliver a working example.

Tones

[AnthonyMuscio]

Post script, we could also have wild card field definitions

• suffix[-link]]?
• menu-item-n
  Tones

[Jermolene]

@pmario's proposal in the OP is an attempt to resolve a long-standing niggle with the way the TW5 core gives special behaviour to certain fields that is hardcoded and can't easily be extended to user defined fields.

The core of the proposal is to use much longer multipart field names that embed type information and other metadata. It's an interesting approach, and it's helpful that you've followed it through with a lot of detail. Generally, I like this kind of speculative design thinking and the discussion it engenders.

In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

I think that as far as the core is concerned, fields should just be strings. At the application level, the kind of conventions you outline might be useful, but those usages need to evolve in the wild.

There are a number of other topics covered here, too. If we want to discuss these further, please can we do so in a separate thread/issue

• @pmario brings up a proposal for extending the .tid file format to allow for multiline field values. I do think we should do this, but I don't think it's a priority for v5.2.0. I would also note that the existing behaviour of the .tid parser is to ignore lines starting with a colon, which I think makes a promising point of extension to retain backwards compatibility (ie, lines starting with a colon could be interpreted as a continuation of the preceding field value)
• @simonbaird asks whether we could use an existing standard instead of inventing our own. I would certainly much rather avoid inventing anything if we can: the .tid file format is inspired by the way that headers and body are transmitted with HTTP
• Simon also asks about YAML. I'm really not a fan, for me it has too much inscrutable special behaviour. I don't think we'd want to be dealing with the inevitable end user issues. https://noyaml.com/ makes a better case than I can

[pmario]

Thx Jeremy, Thx Tony

In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

That's absolutely right. With one of my recent posts I did think about "nesting tiddlers" in fields. IMO technically it would be relatively straight forward. ... It's a nice idea, but adds a lot of "mental" complexity. ...

Which brings up the question: Why doesn't this field contain a transclusion? ...

I do like the idea, that a tiddler can be "self contained" and it can be exported as 1 tiddler. ... On the other hand I did create the bundler plugin, that allows users to "bundle" sets of tiddlers and manage them. ...

May be Tony is right with his approach here: #5805 (reply in thread) ...

I'll need to think about it a bit closer.

[AnthonyMuscio]

Mario, On reflection.

Currently we have the type field that allows a mime type to be set for the tiddler (more specifically the TEXT field ONLY), this then influences how the text field is displayed.

Users and designers can already create other fields, or separate tiddlers than can associate other fields with mime types. I would favour the use of a prefix eg fieldname with fieldname-type containing the mime type.

The missing bit I think is making use of tiddlywikis mime handling on a field other than TEXT, and in the cases where an extra field contains JSON being able to address it tiddler!!filename##index.

If we can expand the tools a little then people can find their own way, eventually we may be able to extend the tiddler format.

I have made it my priority to publish a field and field-type handling solution. And will share it ASAP - I have spent many hours on this already and have good results.

I think when people see this they will be impressed and in a position to develop it further.

Tony

[pmario]

Referring to: #5805 (comment)

Jeremy wrote
In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

I wrote
That's absolutely right. With one of my recent posts I did think about "nesting tiddlers" in fields. IMO technically it would be relatively straight forward. ... It's a nice idea, but adds a lot of "mental" complexity. ...

Now I thought about it again. We do have very complex type definitions already. We are just not aware about them.
Eg: the tiddler class-field is used by the ViewTemplate in a super complex way.

The ViewTemplate defines "how" the class field is used. So the combination between the field-definition and the template is a complex "type" definition.

I think my configuration is less complex, because it is defined in 1 place and not scattered over several places.

eg: the teaser-field form #5805 (comment)

#/_/mime/teaser: rows="4" minHeight="3em"
teaser: text/plain  | -=-=-=-=-                         <- end-marker config for the parser
line 1
line 2
line 3

• defines the a user-field: teaser
• It defines how the filed should be edited: text-input, 4 lines by default, minimum height: 3 em
• It defines how the fiel should be viewed: as text/plain
• and using the end-marker looks very similar to \define macro() ... \end macro which is used for nested macros now

---

Now I want to try to define that definition using predefined Ontologies

IMO it's a nie:plainTextContent. So the question now is, does using this info add more context to the definition.

#/nie:plainTextContent/teaser: rows="4" minHeight="3em" _endString="-=-=-=-=-"
teaser: line 1
line 2
line 3
-=-=-=-=-

IMO it did and it made the configuration easier too. The description of nie:plainTextContent is:

Plain-text representation of the content of a InformationElement with all markup removed. The main purpose of this property is full-text indexing and search. Its exact content is considered application-specific. The user can make no assumptions about what is and what is not contained within. Applications should use more specific properties wherever possible.

And the context where it is defined NEPOMUK Information Element Ontology actually adds a lot of context.

just some more thoughts while thinking about: A PageTemplate from Scratch #7086

[pmario]

TW tags are defined like this:

tags: a b c 

According to: Generic Annotation Example could also be defined like this:

#/noa:Tag/tags
tags: a b c 

nao:Tag is a Class definition that "Represents a generic tag" and has more information related to it.

The good thing now is, if this definition can be handled by TW the following handling comes for free. Which is very hard to achieve at the moment.

#/noa:Tag/tag-like-field
tag-like-field: a b c 

[pmario]

Just a thought: What about the new "compound tiddlers". At the moment the tag $:/tags/wiki-test-spec shows them with a special ViewTemplate.

What if a compound tiddler would be without a tag, but the type: text/vnd.tiddlywiki-compound would use the "Output" tiddler in the "default" ViewTemplate.

It could use the other tiddlers as a specification how to format the EditTemplate.

@Jermolene -- did not like, that my proposal made "mini tiddlers" out of fields. IMO compound tiddlers could nicely solve that problem.

A bit more thoughts and some experiments will be needed.

[pmario]

The discussion at talk: https://talk.tiddlywiki.org/t/storing-formatted-text-but-not-in-the-text-field/12918 and my reply
at: https://talk.tiddlywiki.org/t/howto-use-custom-and-complex-viewtemplates-tagging-and-cascade/12923 made me think again about multi-line-fields

They are a PITA. They make the edit template more complex and we loose the simple .TID file format for saving them. So in the end we do have a "loose - loose situation".

In Dec. 2024 I thought about using compound-tiddlers. The new two threads at Talk, brought me back to think about them a bit more. With a custom edit- and view-template, we could use them in stead of multi-line fields. As @Jermolene wrote

Jeremy wrote
In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

That's right. Now we have tiddlers, that have multiple text-areas, which can handle multi-line wikitext. As a bonus, every one of them can have their own fields for additional meta-data. So we do have even more flexibility in terms of view- and edit-templates.

Status Quo

• We have type: text/vnd.tiddlywiki-multiple ... which allows the data-widget to .extractCompoundTiddlers() and store them in a separated wiki-instance.
• We have tags: $:/tags/wiki-text-spec ... which triggers the test-case specific ViewTemplate
• import-compound ... allows the data-widget to establish compound tiddler "dependencies"
• We do have an "export" compound action, that can split the testcase-wiki-instance into several tiddlers

What's Needed

The testcase-widget uses a hard-coded, view-template, which renders the compound tiddler in a somewhat "static" way.
With type: text/vnd.tiddlywiki-multiple we can create a dynamic view- and edit-template.

• New view-body cascade handling for: type: text/vnd.tiddlywiki-multiple -- no tag to trigger a custom view-template
• New editor cascade to manage compound tiddler EditTemplate
  • Allow multiple edit text areas, including editor toolbars, at the same time
  • may be a new tab-based view similar to the test-case (low priority)
  • Every compound sub-tiddler should be able to define it's view- and edit-template
  • The main tiddler can also have a template and editTemplate field
• New serialiser that allows us to create / write / edit compound tiddlers
  • Something similar to$:/core/templates/tid-tiddler to write files
  • May be eg: $:/core/templates/tid-compound-tiddler, that lets us output a compound tiddler in plain text format
  • Similar to export compound, but instead of creating several tiddlers it writes into 1 compound tiddler
• Every compound tiddler, can have a field: template and editTemplate, that defines their individual templates using the "Edit Template Body" and / or "Field Editor" cascades.
  • So every compound sub-tiddler can have it's own "rendering", "preview" and "editing" UI. -> KISS - for the beginning

Just some more thoughts.

[pmario]

Advantages

• A wiki, that misses all new templates, will still be able to edit a compound tiddler.
• We have a simple .TID file, that can be edited using external editors
• Easy version controlling
• Splitting a compound tiddler into single-tiddlers is easy and the functionality already exists
• Compound tiddlers can be "self contained"

Disadvantages

• It will be hard to explain, to users, when to use that format and when to avoid it
• It will be "misused" for hyper big single tiddlers
• Splitting compound tiddlers will cause "naming-clashes"
• Editor UI will be more complex

Don't Know

• We do not know the performance impact

[Jermolene]

Compound tiddlers are really only suitable for a very narrow use case: packing multiple tiddlers that have been authored by hand. I don't see a viable way to support editing of compound tiddlers as individual textures. (Especially those that contain a single plus symbol on a line by itself).

I am also not keen on the template and editTemplate fields. There is a reason we don't use that approach for ordinary tiddlers: it is much more flexible to be able to specify templates via an external mechanism (eg our cascade).

[pmario]

As I was responding to Springer at Talk: [Proposal: render fieldnames as links, and see what’s possible ..., I was thinking again at compound-tiddlers.

There is a problem with a + sign at the beginning of the line. We have similar problems with CSS wikitext tiddlers. To solve the problem, we use the \rules only pragma.

So what's about a \compound-separator +-+- pragma. So instead of + being the separator for a new tiddler the separator is +-+-. The configuration can be done by the user. So they know, what can cause problems with their usecase.

I think a single + alone at the beginning of a line is not very common, but it is possible. So with the new pragma we have a possibility to work around that problem, in a user definable way.

[AnthonyMuscio]

There has being a "lot of water under the bridge" since we last discussed this. We have revisited it multiple times in other discussions.

One of my latest ideas is not just for system-fields but defining other fields and/or "field types" but to do it in a way similar to tag tiddlers.

It has long being possible to create a tag tiddler given a tag name. It is quite easy to then add content to the tag tiddler or view it with a view template and as a result assign a tag with additional information in the tag tiddlers fields. One can even us the cascades such as view and edit to provide additional handling on tag tiddlers. eg color, caption and icon.

• Tags come into existence by a title existing in a tags field somewhere, that is all. then we have a set of operators that help with tag handling.
• We divide tags into regular and system using the $:/ namespace.

Alternativly we could develop a solution for field tiddlers that works similarly to tag tiddlers but they are found by the field existing on any tiddler. We can develop appropriate cascades (we already have the Field Editor cascade), operators and standard fields such as color, caption and icon. The horse has bolted on tags, but I could see a given fieldname gaining a Field tiddler (missing until created) of the exact name eg fieldname, and if that tiddler contains field=yes then it is a field tiddler, if no look in another name space such as '$:/fieldname' or '#fieldname' (a new optional system namespace) or $:/fields/fieldname.

• Adding a cascade to support this.
• And a cascade to resolve an editor, view fieldname and more, use if available if not use current handling.

Given we are starting afresh with "field tiddlers" perhaps such field tiddlers can be flagged as system or hidden so it need not be part of the fieldname.

• Above mime types etc... could be set in a "field tiddler" to alter the behaviour, parsing etc...

There are still issues to resolve but I feel this is 90% of the way to an acceptable and backward compatible extension into improved field handling.

See https://talk.tiddlywiki.org/t/proposal-updating-field-handling-functionality-in-tiddlywiki/13152/3?u=tw_tones

[pmario]

We are moving in a circle here. Handling the tags field is easy, since the name of the field is fixed. Everything a tag can do can be hard-coded in the core, since the name is known.

As soon as we want a similar functionality like indexes, backlinks, special UI and so on, we need additional configuration information about a field.

This "thought experiment" here is exactly how we can create that meta-data in a somewhat backwards compatible way.

One side effect of the meta data would be the possibility to create multi-line field content.

But

At the end a field + meta data becomes a tiddler as Jeremy pointed out at: #5805 (comment)

In this case, I think the proposal ends up being overly complex because it essentially turns fields into tiddlers: as soon as we add metadata like a "type" to a field, it just becomes a mini-tiddler. Having two levels of the design with the same general features leads to a lot of complexity.

I did see that coming as the "theoretical spec" was able to describe a date-picker jCal format. See post: #5805 (comment) -- That's definitely a tiddler in a field.

The funny thing is, which I never published, it is possible to describe "nested" custom field meta data. That's nice, because it means the spec is flexible enough to specify such configurations. But it's overkill.

---

Some time ago I did come up with the new thought experiment
to "use" compound tiddlers, which contains real tiddlers and would give us the flexibility we need using tiddlers.

Compound tiddlers are multi-line by default. They can have their own fields as many as we want. -> The only thing missing is a simple UI like Edit- and viewTemplates to edit them in a convenient way.

Compound tiddlers, have their own "per tiddler store" which is "air gapped" from the main tiddler store and vice versa. The $data-widget in combination with the $testcase widget are needed to "bridge" the gap between tiddler-store and global-store.

So instead of a testcase-widget it should be possible to design an EditTemplate, that looks like the current edit template, but in reality is the interface to edit a compound tiddler. Nobody would see the difference.

But

We are moving in a circle again. Just a bigger one.

The problem with a compound tiddler is. It is a "mini-wiki" in a tiddler. So we moved the problem from the field level to the tiddler level.

Our users will misuse that concept and will put a 1000 data-tiddlers into a compound tiddler to create a database. -- The funny thing is. That's thinkable and would be fun, with enough time and money.