Re: [tw5] Re: Unrestricted field names... an implied use case

[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  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

On Friday, 18 June 2021 at 02:30:27 UTC+10 springer wrote:

> 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
> On Thursday, June 17, 2021 at 5:54:02 AM UTC-4 jeremy...@gmail.com wrote:
>
>> 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 

Re: [tw5] Re: Unrestricted field names... an implied use case

[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
On Thursday, June 17, 2021 at 5:54:02 AM UTC-4 jeremy...@gmail.com wrote:

> 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
>
> On 17 Jun 2021, at 10:42, Mohammad Rahmani  wrote:
>
> 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
>
>
> On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:
>
>> 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. ... 
>> 

[tw5] Re: Unrestricted field names... an implied use case

[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:  : 

It already has some optimizations for : , 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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/e6ca7ee7-a068-447d-b69d-3118286c2707n%40googlegroups.com.

[tw5] Re: Unrestricted field names... an implied use case

[PMario]

Hi Mat, 
I'm also dreaming at GitHub: How can system-fields look like with 5.2.x 
 
have fun!
-mario

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/ff06ff1a-59e6-479f-accb-5b813f604818n%40googlegroups.com.

[tw5] Re: Unrestricted field names... an implied use case

[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!

<:-)

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/126386ad-9c83-4041-b8fa-67840baf9d8en%40googlegroups.com.

Re: [tw5] Re: Unrestricted field names... an implied use case

[Mohammad Rahmani]

Hi Jeremy,

Thank you for your clarification!

Best wishes
Mohammad

On Thu, Jun 17, 2021 at 2:23 PM Jeremy Ruston 
wrote:

> 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
>
> On 17 Jun 2021, at 10:42, Mohammad Rahmani 
> wrote:
>
> 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
>
>
> On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:
>
>> 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
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com
>> 
>> .
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com
> 
> .
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/FEB2B99E-6A23-42E8-A8B4-5B7A03670E83%40gmail.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Re: [tw5] Re: Unrestricted field names... an implied use case

[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

> On 17 Jun 2021, at 10:42, Mohammad Rahmani  wrote:
> 
> 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
> 
> 
>> On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:
>> 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
>> 
>> -- 
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com.
> 
> -- 
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/FEB2B99E-6A23-42E8-A8B4-5B7A03670E83%40gmail.com.

Re: [tw5] Re: Unrestricted field names... an implied use case

[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


On Thu, Jun 17, 2021 at 11:27 AM PMario  wrote:

> 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
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/CAAV1gMDRxgAA8pZ1nnY56j34uTqw1ux8%2BX0gkqDTcSK-LPkX-g%40mail.gmail.com.

[tw5] Re: Unrestricted field names... an implied use case

[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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/9663224c-7512-4bba-a424-decf876dc943n%40googlegroups.com.

[tw5] Re: Unrestricted field names... an implied use case

[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=<>>
> <$list filter="...filteredtiddlers..." variable=field>
> <>
> 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

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/f6eb47e7-c59e-4272-b7f4-78b2acc288b7n%40googlegroups.com.

[tw5] Re: Unrestricted field names... an implied use case

[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
On Thursday, 17 June 2021 at 01:12:19 UTC+10 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=<>>
> <$list filter="...filteredtiddlers..." variable=field>
> <>
> 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=<>>
> <$list filter="...filteredtiddlers..." variable=field>
> <$transclude field=<>/>
> 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=<>>
> <$list filter="..." variable=tid>
> <$vars template={{{ [get] }}}>
> <>
> 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 
> 
>
> <:-)
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/18be46dd-6383-4574-ac1a-db11dbeba713n%40googlegroups.com.