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 On Tuesday, 4 May 2021 at 16:48:36 UTC+10 [email protected] wrote: > 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 > Le mardi 4 mai 2021 à 02:48:55 UTC+2, TW Tones a écrit : > >> 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 >> >> On Tuesday, 4 May 2021 at 10:21:51 UTC+10 [email protected] wrote: >> >>> 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: >>> >>>> 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 >>>> >>> -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/27435ea8-6b15-4193-9293-bcd92f98e9e7n%40googlegroups.com.
