[Discussion] Field Related or subFields

[TW Tones]

Folks,

I have come across a "problem" for which I am investigating a solution, and keen to hear any ideas. ultimately I hope this to provide a generic solution for advanced field handling I would share back into the community.

Problem:

Consider we may like to have a field in one or more tiddlers to store a url to an external resource for that tiddler.

Field: url, Value: https://tiddlywiki.com/#cycle%20Operator

The thing is what if we wanted to store a simplified name such as "Cycle Operator" or a target for links such as _blank or "operators" there is no where to specify the url/name and url/target. when we construct a link to this URL it would be nice to find the name/target for this url field/tiddler combination.

In future I also want to have a discussion-link tiddler with matching name and target, with even more similar fields.

Possible approach

We could use the "_" underscore to delimit such "subFields" and create additional fieldnames such as url_name and url_target. Then when I have code dealing with "url" it can look for fields beginning url_ to find its "subfields". I wonder if this compromises the available fieldnames or others plugins and solutions that make use of the "_" underscore more often than I do?

Perhaps such fields that may have subfields could end with "_" eg; "url_" meaning subfields exist for this fieldname.

More complex systematic approach

I could store in a data tiddler (For each tiddler) these additional subfields, or even in a new special text field inside each tiddler.

A not so desirable approach

Build all the handling to allow the url field (in this case) actually be the full http link or html <a> tag. The problem being one may need to code and decode the content of the url field for every add or change, also if one had dozens of different link fields it could get messy.

Your Thoughts?

Tones

[PMario]

On Monday, May 3, 2021 at 8:35:10 AM UTC+2 TW Tones wrote:

Possible approach

We could use the "_" underscore to delimit such "subFields" and create additional fieldnames such as url_name and url_target. Then when I have code dealing with "url" it can look for fields beginning url_ to find its "subfields". I wonder if this compromises the available fieldnames or others plugins and solutions that make use of the "_" underscore more often than I do?

Perhaps such fields that may have subfields could end with "_" eg; "url_" meaning subfields exist for this fieldname.

TW uses _canonical_uri for some "special handling already". So from my point of view it could use _uri  SEE "i" not "l" for something special that expects additional info that can be used to define a proper html A tag.

IMO most users will use url for their field names.

just my thoughts.

-mario

[PMario]

We may have to have a look at the spec: https://tools.ietf.org/html/rfc3986 ... Just to be sure, that we don't violate best practices too much ;)

-m

[Charlie Veniot]

What about if you have multiple url resources for a tiddler?  Is that a flexibility you want?

Or do you only ever want { 0:1 } url resource scenarios per tiddler?

[TW Tones]

Cj/Mario,

The url is simply one example. I am looking to be able to provide a method that any field can have additional supporting values. The idea that a url/uri field may have an accompanying name or target field is a good example of this.

The idea would be to find a de facto standard and mechaisium to do this.

• I will consider the methods in the use of  _canonical_uri

On multiples, url/uri is BUT one example. In my own application I intend also have a mechaisium to allow any fieldname-link (suffix -link) to contain a URL and want to find a way to also give these name and target values in the same tiddler. 

But the same could be for other fields, for example 

• Perhaps I could give the color field a color-name for display/selection.
• Or a list field a saved list field.

Another method I have considered is an additional text field in a tiddler that can contain dictionary or json entries supporting additional "virtual fields".

Thanks for considering this issues.

Tones

[Charlie Veniot]

Just quick thoughts.

Although easy enough to build a mechanism for virtual fields within a field, would you be knee-capping many plugins that would know nothing about virtual fields?

I'm thinking it might be beneficial, instead, for every tiddler to have a matching data tiddler for an unlimited number of index fields that are all real/atomic.

That aside, how about fields actually be like data tiddlers?  i.e. each field that has virtual fields actually has a json structure ? So taking advantage of a native mechanism, just tweaking it to work with tiddler "data fields  à la JSON" instead of data tiddlers à la JSON.

[TW Tones]

cj,

Some interesting ideas there, I would be inclined to use a dictionary tiddler containing "subfield: value" as it is easier to read, and edit manually than JSON, unless we had some more edit JSON field tools. Yes this can be a separate tiddler or a special field within tiddlers (preferred because then you can drag and drop between wikis and carry the subfield values).

In the original post I was placing under consideration the idea that a convention would be that a field such as "discussion" may also have a discussion_name and  discussion_target field. What ever handling I do for "discussion" I can test for the existence or or attempt to get the values in one or more "discussion_" fields. 

With this above method you can see a de facto standard and a small set of macros could help "make use of" these "subFields" but they can also be accessed independently if needed. 

With a "generic set" of supporting macros I could then redeploy these to provide a my-link,  my-link_name and  my-link_target. I imagine a macro <<subfield fieldname subfieldname>> <<subfield discussion name>> returning the content of such a field or empty or default value.

Not withstanding the above I do not want to poison the issue with my own ideas, and wonder if there are smarter ways to achieve the same outcome. This is systematic and conceptual so I am not surprised you and Mario are currently the only responders.

Thanks again

Tones

[Charlie Veniot]

Underscores and dashes are pretty similar looking.  If that matters any (i.e. if you already use either one in field names), then how about a period?

So "url.", looks nice to me.  Then you could have url.name, url.target, etc.

That becomes just a matter of personal preference.  I think they are all fine for what you're thinking.

On Monday, May 3, 2021 at 3:35:10 AM UTC-3 TW Tones wrote:

[TW Tones]

Charlie,

Good idea. If I wanted to reduce the clashes I could use ".." unlike double __ or -- .. is clearer. and the chance others are using ".." is lower. then we can safely search for all "Related fields" ie; and field name containing ".." eg discussion..name supports the field discussion with a name. Disambiguation from other fields using _ - or . which are permissible.

Now I need to automate in some way the identification of related fields and there use in code/wikitext.

Tones

[Jean-Pierre Rivière]

A while back', I had a field having structured data like "Potter^14^sorcery" but it was up to my macros to handle them. Say that field was called "identity". If I understand your proposal correctly, under your scheme, it would be called "identity." and its 3 sub-fields known as "identity.name"', "identity.age" and identity.business". But how would they be stored? And retrived? Anything that could streamline the handling of such things would be cool.

I fail to see what you concretely wish to get.

It seems to me that these smart fields would lesser the need to have json data. Or maybe we could just have fields store json data and get methods for accessing json au part of the core? Thus, we would be able to handle them but also json in the text field, which is only a field like other.

regards,

-- 

Jean-Pierre

[PMario]

On Tuesday, May 4, 2021 at 1:48:33 AM UTC+2 TW Tones wrote:

In the original post I was placing under consideration the idea that a convention would be that a field such as "discussion" may also have a discussion_name and  discussion_target field. What ever handling I do for "discussion" I can test for the existence or or attempt to get the values in one or more "discussion_" fields. 

For me this looks like a mechanism, for inheritance. ... Similar to a possibility to define a field, that behaves like the "tags" field.

eg: my-tags..type: tags .... Which would look up the "setters" and "getters" from the tags field to read and write there.

similar: due-date..type: date ... Has the same functionality as created and modified.

So the existence of due-date..type implies the existence of due-date.. and hides them both from the edit-template.

So due-date..macros: $:/tiddlerName  contains the macros, that are "inherited"   If ..macros doesn't exist it assumes tha name to be $:/fields/macros/<type>/ In norm al cases ..macros is used for development and $:/.. is used for production.

... Just brainstorming

-mario

[PMario]

On Tuesday, May 4, 2021 at 8:48:36 AM UTC+2 jn.pierr...@gmail.com wrote:

It seems to me that these smart fields would lesser the need to have json data. Or maybe we could just have fields store json data and get methods for accessing json au part of the core? Thus, we would be able to handle them but also json in the text field, which is only a field like other.

If we want user-facing wikitext functions that can handle JSON, imo we would need a "schema", that defines the behavior.

This is 1 level "higher" than my previous thoughts.

just brainstorming.

-m

[TW Tones]

Jean Pierre,

We sound like we are on the same page, my idea was to store the fields by that compound name, just as "complementary fields"" fieldname..description could describe the content of the specific "fieldname" on this specific tiddler.

Concretely what I wish to get is additional information stored per fieldname on a given tiddler, complementary fields. The first case was an anyname.link (containiong a URL) field can have the complementary fields  anyname.link..name  anyname.link..target

However to assist many anyname.link fields I want the use of the complementary fields somewhat automated, perhaps only a de facto standard, with supporting macros as needed.

I see this need for a method by which to have  complimentary field names quite compelling so supporting tools can be built once and used by many.

Tones

[TW Tones]

Mario,

You speculation sounds interesting, but I do not fully grasp it.

In relation to inheritance I have build a few applications on tiddlywiki that define a fieldname by creating a "fieldname" tiddler (like you can with tags tiddlers), within that there are fields that define the "default values" and other details, however the most critical is the field-type field, each field-type eg date, also have a tiddler of their own and they contain fields for modes (read-only view update edit and design). In each of these field-type's mode fields, I place the wikitext and macros to operate on the field in each mode. Fieldname tiddlers may also have a values-filter used in the field-type to provide a select in edit and update modes.

Then I access any field in the body of a tiddler or view template with <<field fieldname>> and this macro is sensitive to the field definition, its field-type and its mode. Once can also force the mode <<field fieldname edit>> (but not if in read-only mode)

There will always be more fieldnames than field-types because many fields can use the same field-type eg; date, short-text, prose. With a structured design one can collect fieldname definitions and the related field-types and share these among wikis for rapid development.

With the above already in the wings, you can see how needing these complementary fields is another dimension in creating comprehensive mechanisms for solutions. It would be interesting to consider if a fieldname defined using the above mechanism (fieldname/field-type/mode) could be designed to support the "complementary fields".  For example if the fieldname is created/populated on a tiddler its fieldname..displayname would be created and a default set. In the tiddler (template) the designer could place <<field fieldname "" related>> to display the complementary fields in the tiddler mode. eg read only may only show a hyperlink with the name and target, edit mode the way to edit name and target.

I can share some examples of my prior work on this is anyone is interested.

Tones

[PMario]

On Tuesday, May 4, 2021 at 9:44:50 AM UTC+2 TW Tones wrote:

...

I can share some examples of my prior work on this is anyone is interested.

That would be nice!

But I want to get a bit further. If we define due-date..type: date   Something like this should be possible.

<$action-setfield $tiddler=xx $field="due-date.." $value="Sept 20th" />  the result should be

due-date.. = 20120920    because: somewhere we have due-date..YYYY: 2021 due-date..edit-template:"YYYY mmm DDth"

This would allows us to define sensible defaults.  due-date..edit-template:{{date-format}} should be possible too in a second step

I also want to be able to use: long-ago..type: xxxxx   that understands. 500 mil years ago

just dreaming

-mario

[PMario]

Hi,

I still want to have  sec-expanded-years as in https://groups.google.com/g/tiddlywiki/c/YaFzHXfjnFc/m/jpQJrSi8BwAJ

and: SI prefix multipliers as in: https://groups.google.com/g/tiddlywiki/c/YaFzHXfjnFc/m/l5S9-TnaBwAJ from the same thread.

mario

[PMario]

On Tuesday, May 4, 2021 at 11:27:49 AM UTC+2 PMario wrote:

I still want to have  sec-expanded-years as in https://groups.google.com/g/tiddlywiki/c/YaFzHXfjnFc/m/jpQJrSi8BwAJ

and: SI prefix multipliers as in: https://groups.google.com/g/tiddlywiki/c/YaFzHXfjnFc/m/l5S9-TnaBwAJ from the same thread.

And I want, that TW-fields can handle this. eg: long-ago..from, long-ago..to  

just an idea ;)

-mario

[Jean-Pierre Rivière]

".." is commonly used in describing a continuation, for instance 3..7 is for 3, 4, 5, 6, 7.

IMO the proposed use of .. is then counter-intuitive.

I prefer a simple dot.

We could use an arrow but -> is awkward in an html oriented language so it's a no-starter.

We could use ^ but it may interfer in regexp. it would probably be no big deal though.

We could have a mix. for instance:

main field is "date."

sub-fields are "date.^value" or "date.^format" or "date.^units".

the other way around:

main field is "date^"

sub-fields are "date^.value" or "date^.format" or "date^.units".

question: are sub-fields regular fields in the end, just being taken in charge by a set of ad-hoc macros and filters and templates? there would be a lot to tinker depending of the choces being made. or are sub-field a brand new mechanism of 1st-class core components?

just suggestions...

-- 

Jean-Pierre

[TW Tones]

jean-Pierre

Field Names are quite limited

TiddlerFields are name:value pairs that make up a [[tiddler|Tiddlers]]. Field names must be lowercase letters, digits or the characters `-` (dash), `_` (underscore) and `.` (period).

https://tiddlywiki.com/#TiddlerFields

The .. considered as continuation actually works from my perspective eg url.. is continued elsewhere in url..name.

In answer to your question, yes they should be regular fields you can use in every other way if possible. The question is what is the defacto standard and how do we best implement support for such fields. Can we provide a generic solution?

Tones

[Jean-Pierre Rivière]

oups. forgot that restriction. I mostly work with indexes (greater liberty for names)

what about main. and main._.sub ? ._. is seen nowhere else and is rather cute and evoke a SUBtil smile.

[PMario]

On Tuesday, May 4, 2021 at 12:26:30 PM UTC+2 jn.pierr...@gmail.com wrote:

".." is commonly used in describing a continuation, for instance 3..7 is for 3, 4, 5, 6, 7. 

IMO the proposed use of .. is then counter-intuitive.

I don't think so. We probably don't use field names 3..7. We use field-name..meta-data ... I don't see a problem there.

Everything else dosn't look good, is forbidden or is hard to write.

If we use dots in regexp, we need to escape them anyway. So there shouldn't be a problem with regexps.

just my thoughts.

-mario

[TW Tones]

Mario,

Ah yes, these related fields could be for a range  long-ago..from, long-ago..to meaning there is no need for long-ago or long-ago..

We need to be careful we do not confuse the type with the fieldname. I would not expect a fieldname.type in any tiddler but perhaps in a dedicated fieldname tiddler.

Thus there may be a tiddler named long-ago..from and another long-ago..to which include a field called field-type=ancient which demands a negative number or 0 ? and has a "year" as its units.

I once thought that I must decide on a set of modes that either the tiddler or a specific field can be "displayed in" such as view update(click to change) edit already in edit mode etc...

During this thread I have come to realise each time we add a field we can also add it to more than one mode tiddler eg edit-mode which can contain the wikitext for that field in edit mode, in fact all fields wiki text in edit mode. And another for view and update, I can just add another mode tiddler eg designer and decide what wiki text markup to use for the field in this mode.

The trick is to simplify this so you start with a default related to the tidler type, for example a view provided for long-ago..from woul;d be {{!!long-ago..from}} if I put the tiddler into edit mode, it looks to see if this field has an entry in the edit mode tiddler, if not it "steps back one" and inherits the view mode.

It would be easy to scan the wiki and identify all fields and store them in a view mode tiddler just with the {{!!fieldname}} as an initial value. Do the same for editmode and place in each field in the tiddler the code to edit each field defaulting to text edit. However as pointed out before having a field-type determine how to view or edit is more precise. Thus on creating a field add the field name to a $:/fields tiddler and provide a default field-type, then in separate mode tiddlers provide the wikitext to handle that field type in that mode.

I am working on an example now, and using some buttons to populate default fields.

Tones