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. On Monday, May 3, 2021 at 8:14:25 PM UTC-3 TW Tones wrote: > 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 > On Tuesday, 4 May 2021 at 02:35:53 UTC+10 [email protected] wrote: > >> 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? >> >> 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/cb4210b8-8aee-4613-a2bf-b5d50a998e92n%40googlegroups.com.
