Use tag-picker to dynamically pick target tiddler

,
#1

In my Gift Ideas notebook I’m using the following logic/structure:

title: Person A
tags: person

title: Gift 1
tags: gift
to-gift: [[Person A]]
already-gifted: [[Person B]] [[Person C]]

I’m using templates to add a <<tag-picker>> on each person, listing all available gifts (minus those already planned and already gifted, hence the -enlist) and add their name to the selected gift:

<$macrocall
$name=tag-picker
tagField=to-gift
tagListFilter="[tag[gift]] -enlist[tag[gift]search:to-gift,already-gifted{!!title}]"
/>

The above is wrong: it saves the sellection on each person and not on the selected gift.

Theoretically I should define the tiddler parameter in tag-picker but what should I put there? I don’t know the target tiddler yet, that’s what I’m using the tag-picker for :sweat_smile:

edit: I’ve already implemented the opposite flow, selecting persons from within a gift and it works without complications, it’s simpler the other way round.

#2

Does this mean you solved your problem?

In general, your challenge here reflects the general structure recently discussed elsewhere: Where to store information that is essentially about relations (including events that connect people, places, and things)?

Options are:

  1. Have the person-tiddlers store which gifts a person has gotten (and may get in future).
  2. Have the gift-type-tiddlers store which persons have gotten that kind of gift, and which ones are planned recipients for it.
  3. Have something like “line-item” tiddlers — probably living “behind the scenes” — that represent a person-gift-“transaction” as it were. More broadly, we can call it a “relational node”, just dedicated in this case to one gift-interaction (which then can be seen from wherever it’s relevant).

The first two solutions are simpler, and you’d just need to be consistent. (Whichever kind of tiddlers “hosts” the data shows it directly, and the other kind of tiddler uses filter language to display related data from where that data lives.)

The third kind of solution is very powerful, and of course a bit more difficult to set up.

Using behind-the-scenes “relational-node” tiddlers has some advantages: it would be easy to have any level of detailed “meta-data” about particular “transactions”:

  • gift: Wallet gift-for: Mary occasion: 21st-birthday date: 2024-12-01 result: delighted!
  • gift: hat gift-for: Nora occasion: Valentines date: 2025-02-14 result: returned notes: too big
  • gift: socks gift-for: Bob occasion: Halloween date: 2025-10-31 tag:future

The more you may be tempted to track things about gift-givings beyond “who?” and “what?”, the more the third solution would make sense.

  • gift: grill gift-for: Phil occasion: wedding date: 2023-06-30 gift-by:Pat notes: “said he owes us a cookout party”

For example, you may not want to give your brother something too similar to the gift that your spouse gave your brother last year, and you don’t want to give something you happen to know they already have…

So maybe you would want to track gifts given by certain others (or simply the fact that Phil already has a grill, leaving out who bought it and when). But still you want to do this without setting up confusion down the line over things like who gave that great sweater to your brother…

Also, you may suddenly realize you want to track some incoming gifts — because it’s nice to remember and appreciate them over time :innocent:, and also few things are more awkward than giving your cousin the very same book that the cousin already gave you. :grimacing:

If you go with solution #3 (relational events each get their own tiddlers), then you may suddenly attend to new dimensions of the data, and realize you have new powers: a filter to show “What kinds of gifts have been given for Halloween?” or “How much have I spent on gifts for Bizzy, and how much for Bazzy?”)

TiddlyWiki is great for flexbility: it can be a casual set of notes with a few tags and simple fields, or it can be a robust relational database, able to reflect the specific data-structure that your subject-matter would deserve if it were a business or expert-hobby-level priority.

Your gift-idea wiki could be anywhere along that spectrum! If you want to go “all out” and set up the third kind of solution, feel free to come back and ask for help!

For all projects that involve “refactoring” (moving existing info from one “home” to another, from tags to fields, renaming fields, etc., as your solution grows or solves problems) I recommend the Commander plugin from @Mohammad: Commander Plugin 2.1.14 — Streamline tiddler management: bulk operations for titles, tags, and fields

#3

Unfortunately I haven’t. I added that edit to make clear that I have half of my needs covered, ie adding persons to gifts. I’m still missing the other half, adding gifts to persons. It’s only after I edited that in I realized, it might read like I’ve solved my need.

Optimally I really hope(d) that using some form of intermediate variable (?) would allow me to set the <<tag-picker>> target-tiddler dynamically. As it stands it would be the simplest approach and get me much, much closer to where I want to be.

As a project history side-note, when I begun this notebook I thought I could get away simply by tagging gifts with persons directly, then using the <<toc>> macro to emerge the structure. I quickly realized simply tagging wouldn’t capture past- and future- gifts. So, I moved on to the current approach of using fields. At some intermediate moment I too thought of using a triangular relation, having persons, items and gifts linking the two. Binding and managing the three of them seemed quite complex (and still does tbh).

I’m not sure I need all that information captured, at least not on this project. Although I’m sort of using it as a test bed for a more complex idea I have for a work-related thing I might try to build at some point.

Just spitballing, going for the triangular linking I’ll probably need to tackle the following

  • A form that would easily create middle gift tiddlers linking items and persons, for example having 2 dropdowns and a Link button
  • A means to alter (create/update/delete) those links from either end: add items to persons and persons to items. It’ll probably need to be a 2-step process, for example:
    • On [[Person A]] , select any of the gift links with their name in either the to-gift or the already-gifted fields.
      • Decide what to do with the gift link OR
      • Create a new gift

I’m not sure I won’t fall again in the trap of having to set target-tiddlers dynamically, I haven’t really thought this through yet. Having more middle steps probably reduces the need for dynamic targeting but also increases the complexity.

#4

Just make sure you consider;

  • Store a relationship in one place not two so you do not need to maintain a two way link
    • this may result in more than one selection method for each context. eg one adds value to current tiddler, the other adds a value to a field in another tiddler.
  • If the relationship is many to many consider an intermediate index (I know logicaly but have not yet made one)
    • Or a tiddler for each relationship itself.
  • Use and configure the relink plugin to support renames of titles within fields to support referential integrity (avoiding complexities with change and maintenance).
1 Like
#5

I will Just add here that field names are now able to use the same characters that we use in titles, so with a little extra handling we could create a field for any title and use its value to set one or more relationships as values. Possibly avoiding the need for an intermediate index in many to many relationships.

  • Not many if anyone has explored this posibility to my knowledge.

Thanks for bringing this to mind at the same time I am working on [Proposal] Updating field handling functionality in TiddlyWiki

This is to make the reply substantialy different from one I just deleted