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 cj.v...@gmail.com 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 tiddlywiki+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a75f46b9-bd97-4af4-9a51-61ae36eeb6f8n%40googlegroups.com.
