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 On Tuesday, 4 May 2021 at 09:27:45 UTC+10 [email protected] wrote: > 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/7c1968a0-537b-4cf8-8f53-522b138a82d4n%40googlegroups.com.
