Unrestricted field names... an implied use case

[Mat]

Just thinking out loud...

As you may know, the coming v5.2.0 will feature unrestricted field names. This is very big news! This will push fields to a substantially more prominent position because fields can then be directly mapped to tiddlers. I mean, just look at this:

"In the current tiddler, get the values of the fields with names that match a filtered set of tiddler titles." 

\define getdata() {{$(curr)$!!$(field)$}}

<$vars curr=<<currentTiddler>>>

<$list filter="...filteredtiddlers..." variable=field>

<<getdata>>

etc

So, the field values could be a relationship between the current tiddler and those other tiddlers. For example:

title: Adam

Barbara:mother

Caesar:father

David:friend

...or from the other direction, i.e "In a filtered tiddler list, get the values from the field(s) named as current tiddler":

<$vars curr=<<currentTiddler>>>

<$list filter="...filteredtiddlers..." variable=field>

<$transclude field=<<curr>>/>

etc

Another use: "Transclude the content of a filtered set of tiddlers using templates. But which specific template is used depends on the relation the tiddler has with the current tiddler"

\define getdata() {{$(tid)$||$(template)$}}

<$vars curr=<<currentTiddler>>>

<$list filter="..." variable=tid>

<$vars template={{{ [<curr>get<tid>] }}}>

<<getdata>>

etc

...so, for example, if the relationship with current is "closest family" then apply the template that also shows a photograph.

Here the "getdata" macro only does a template transclusion but if the field values contain complex data such as "Queen Elizabeth: sister queen [[pole dancer]]" the macro could of course do much more complex stuff treating such values as flags or variables etc.

IMO the next bottleneck related this matter, are tools for controlling field values. One such discussion is CheckboxWidget - generalize to also toggle individual items #5613

<:-)

[TW Tones]

Mart,

I am execited about this too, see and vote for my Idea here 

Which reads;

is/all operators to include fields and new system fields! V5.2.0

Folks,

Would it be possible to add to the next version is[field] and all[fields]] such that a title can be tested to see if it is a fieldname?

The following filter can already determine this;
[fields[]match[test-field]then[yes]else[no]] equivalent would be [[test-field]is[field]]

However since fields are a important element of tiddlywiki, it would be helpful and make readable a range of field handling designs.

An extended feature would be to have virtual tiddlers for such fields like tags currently have a virtual tiddler, you can open and create if desired. This will be even more appealing with the new expanded tiddler naming rules because one could arguably have system fields ie those beginning with $:/ which are optionally hidden from view and edit templates, but certainly will not come up in the sidebar search.

An added feature of the extended field naming in 5.2.0 is designers and developers can use fieldnames with their own prefix eg I use $:/psat/tiddlername I can also use $:/psat/tagname so it would be nice to use $:/psat/fieldname

I also had a previous request that I thought was being implemented, that resulted in this https://github.com/Jermolene/TiddlyWiki5/pull/5315

I hope it can proceed.

This may also be related https://github.com/Jermolene/TiddlyWiki5/issues/1324

Regards
Tones

[PMario]

On Wednesday, June 16, 2021 at 5:12:19 PM UTC+2 Mat wrote:

Just thinking out loud...

As you may know, the coming v5.2.0 will feature unrestricted field names. This is very big news! This will push fields to a substantially more prominent position because fields can then be directly mapped to tiddlers. I mean, just look at this:

"In the current tiddler, get the values of the fields with names that match a filtered set of tiddler titles." 

\define getdata() {{$(curr)$!!$(field)$}}

<$vars curr=<<currentTiddler>>>

<$list filter="...filteredtiddlers..." variable=field>

<<getdata>>

etc

So, the field values could be a relationship between the current tiddler and those other tiddlers. For example:

title: Adam

Barbara:mother

Caesar:father

David:friend

It will be hard to create an efficient algorithm with this setup, in wikitext. You have 2 variables here.

 - The field name

 - The field value

As a developer you neither know which "name" a user will use and you don't know the values which are used. .. So how do you want to create an algorithm?

You need a configuration tiddler somewhere. .. This problem has been the same for ages.

So having "freeform" field names alone won't solve any of the problems you describe here. .. In the contrary. It will open up new problems and edge cases, that we don't even know yet. ...

just some thoughts

mario

[PMario]

Let me be more specific eg:

>So, the field values could be a relationship between the current tiddler and those other tiddlers. For example:

>

>title: Adam

>Barbara:mother

>Caesar:father

>David:friend

You mentioned that having upper-case letters in the field names can help to solve the "relationship problem". ..

I ask: Where is the difference from a setting below and your suggestion?

title: adam

barbara: mother

caesar: father

david: friend

There is no difference. The setting in the example has been there since v5.1.0 .. and the problem isn't solved. ...

So as I wrote: Having more possibilities in the field names won't solve anything. Sorry.

-mario

[Mohammad Rahmani]

Like Mario, for me it is not clear what will be the benefit to have such liberty in naming fields!

I think Tiddlywiki is growing organically! Sometimes you need to see good and consistent logic to be able to write better code to understand and maintain!

So, while I am not against the new feature in TW 5.2.0 but I really like it, we are going toward a more consistent, easier to learn and easier to maintain grammar and syntax!

Best wishes

Mohammad

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com.

[Jeremy Ruston]

One thing to bear in mind is that the core has always supported unrestricted fieldnames for almost all operations. The primary thing that's changing now is that the switch to the JSON store area allows us to guarantee that arbitrary fieldnames will be respected over a save-and-reload cycle. The secondary thing is the removal of the very weak protections against creating fieldnames containing arbitrary characters.

Perhaps there a relatively small number of usecases for complex fieldnames, but some of those use cases are powerful and so seem important. But even in the absence of important use cases, a very important benefit is that unrestricted fieldnames make TiddlyWiki significantly simpler to explain. Every little arbitrary restriction or caveat adds to the conceptual load for people learning TiddlyWiki.

For me, one of the most important consequences is that we can encode variable name/value pairs as fields. For example, in the new publishing framework that is under development we represent a publishing job as a configuration tiddler that specifies the template to be used, the filter identifying the tiddlers to be output, and a collection of variables to be provided to the rendering. The variables are expressed as fields named "var-foo", where "foo" is the name of the variable, and the field value is the value for the variable.

It's a simple and flexible approach that wouldn't be possible without loosening the restrictions on field names.

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

https://jermolene.com

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com.

[Mohammad Rahmani]

Hi Jeremy,

Thank you for your clarification!

Best wishes

Mohammad

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/FEB2B99E-6A23-42E8-A8B4-5B7A03670E83%40gmail.com.

[Mat]

Guys, thanks for input.

PMario, please explain the problem you describe a bit more because I don't understand. 

You exemplify and ask the following:

I ask: Where is the difference from a setting below and your suggestion?

title: adam

barbara: mother

caesar: father

david: friend

So here's a counter question: Would it not matter for you if we introduced very limiting naming restrictions for tags? Surely you must agree it makes a big practical difference.

But I don't understand how your example exemplifies the problem you describe, i.e:

> It will be hard to create an efficient algorithm with this setup, in wikitext. You have 2 variables here.

>  - The field name

>  - The field value

> You need a configuration tiddler somewhere. .. This problem has been the same for ages.

What do you mean with "configuration tiddler" here? In my "family" example, what would a config tiddler do or be - and why is it problematic? Where would there be a problem with an "efficient algorithm"?

Thanks!

<:-)

[PMario]

Hi Mat,

I'm also dreaming at GitHub: How can system-fields look like with 5.2.x

have fun!

-mario

[PMario]

On Thursday, June 17, 2021 at 2:40:05 PM UTC+2 Mat wrote:

...

title: adam

barbara: mother

caesar: father

david: friend

...

> It will be hard to create an efficient algorithm with this setup, in wikitext. You have 2 variables here.

>  - The field name

>  - The field value

> You need a configuration tiddler somewhere. .. This problem has been the same for ages.

What do you mean with "configuration tiddler" here?

In my "family" example, what would a config tiddler do or be - and why is it problematic?

The algorithm will need some info about the possible relation values. eg: mother, father, friend, child, ... and so on. If it doesn't know what is possible it can't handle it. There is nothing problematic with config tiddlers. ... I just wanted to point out, that "freeform field names" is not a solution for the "relation problem"

 

Where would there be a problem with an "efficient algorithm"?

In your example, you use lists. Lists need filters and filters have to be fast. They can only be fast, if they internally don't have to make lookups in the wiki store. Especially if they have to touch every tiddler in the store. The core doesn't know about your structure eg: <name> : <relation>

It already has some optimizations for <relation>: <name>, because there are probably more fields eg: father: xxx than xxx: father. In your OP xxx is a tiddler name and tiddler names are unique. so there will be only 1 xxx field and all the relations have to be looked up, which is slow.

-mario

[springer]

Jeremy and all,

I too am *very* excited about this, especially given my dependence on dynamic tables. 

First, a small confession: I've already been using short special-character fieldnames for a while, sneaking around the protection by setting them up as column names in Shiraz dynamic tables, and then editing those tables. One use: column headings like § and @ that allow for compact and intuitive presentation, when the column data tends to be single-digit. But this is a superficial cheat (since these have been old-fashioned property-like fields).

More importantly, isn't this v5.2.0 step a path to more powerful (multi-dimensional) relational data, or at least virtual pivot-table behavior? 

Suppose a use-case that involves spread-sheet-like relation between tiddlers (rows) and fields (columns), where the field-names tend to have their own tiddlers (which until now we've named in the constrained way).... 

Starting wth v5.2.0, can't field names can serve better as the intersection (cell) of these two dimensions? Values at the intersection should be more readily accessed via either axis of the table, so that what appears in Tiddler A, field F, also *could* be referenced easily within tiddler F (That is, F can be set up with filters to draw info from all tiddlers that use F as a field name). 

I imagine the intersectional-field-data housed remotely (on the other "axis") could be rendered like virtual fields (within a filter-condition ViewTemplate)... and it may even be possible to reach through and edit the remote intersection-field directly.

For true pivot-table purposes, a plugin could flag or help correct discrepancies between A's F-value and F's A-value, no?Obviously, this would have to be an optional feature, or one that hangs on some further condition, since some uses might call for A's F-value to differ from F's A-value -- especially on legacy projects built without intersectional power in mind.

I welcome corrections or clarifications from those who actually understand the guts of TW5!

-Springer

[TW Tones]

Folks,

I have constructed various fieldnames over the years that make use of naming standards such as menu-item1  menu-item2 or link/named-link/another-link where my code can find all fields on the current tiddler or throughout the wiki say with the suffix "-link" and then determines the prefix and returns that as a value eg; the link "another" containing the url found in another-link. 

In the above cases you can see the hyphen acting as a delimiter, with the lifting of naming restrictions on fieldnames I can see being able to use other delimiters such as : or even :link, I really like this freedom, but also wonder if we should preempt such flexibility with some de facto standards that we tend to use, eg in the above "link" is naming a field "type" in the name of the field. fieldname:link and we use link to identify how to display that fieldname eg; inside a html <a> element.

I am also keen to have a de facto standard so we can build index tables in tiddlers for one to one, one to many or many to many relationships. For example fieldname:indextiddlername where the value(s) in such a field is a key to an index tiddler "indextiddlername" that contains one (or more) entries for that key, the entries may be values or "other tidder" names (other keys). The "other tiddlers" could also access the index.

Although these structures can be already emulated in tiddlywiki with such de facto standards we can build sharable tools to support such sophisticated relationships. Do it once share and reuse many times.

With carful use such structures could help with the performance of tiddlywiki when building larger and more sophisticated relationships/databases, while in a way stepping to the side of the tiddler refresh cycle.

Regards

Tones