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/e6125dbb-d81c-4251-b9d1-f3fe0a935a8en%40googlegroups.com.
