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/d6e6c090-0e56-4367-beaa-e2d31c690df0n%40googlegroups.com.
