Tinderbox Forum

Hacking a dynamic "suggested values" list

I have a prototype for Person which includes a field called $Employer. Each Employer has their own note (with a prototype of Organization) and is included in a container called Organizations.

The list of organizations is fairly stable, but when it grows, I tend to have a number of people to add as well: thus, I wanted to be able to change the suggested list for $Employer automatically.

Unfortunately, gathering the values of tag $Employer into a variable through:
$MyVar = values("Employer").isort
is not sufficient, as I have no way to programmatically populate the suggested values list with $MyVar

However, I came up with a roundabout hack: the Organization prototype has a rule:
$Employer = $Name
So whenever I create a new organization, the $Employer suggested list, being populated by all the existing values, is modified to reflect the new entity.

This really got triggered by the following phrase in aTBRef’s entry for suggested values :

This method replaces an older approach of making ‘seed’ notes a placeholders for desired prepared values.

Of course I may be missing a simpler way around this problem

1 Like

This is neat. It took a moment to figure it out. In this case, the suggested values aren’t being touched but the overall list of used values for $Employer is being incremented by the new notes. However, as the notes doing this work are of (proto)type Organization and not Employer, then it is still possible to filter out $Employer values only used by Employer notes (or Employee note, or whatever).

Edit: and the quote from aTbRef allowed me to spot and fix a typo. Extra win! :grin:

just starting to think on how to do it and … so simple and effective. Thanks!

2 Likes

My approach is to maintaining suggested values in a set or list attribute, is to use a special note I call a “set collector”. In the example Tinderbox document attached below, the set collector for Areas is this:

Adding a note to the /Areas container will cause the set collector to update the suggested values for $Area. This uses a Rule, could be an Edict, or the set collector could be an agent. If it was an agent then it could have extra logic to overcome the greatest weakness in my system: changing the $Name or deleting a note in /Areas does not update the attribute value in the notes that use $Area. For me that’s really an edge case, though.

Members.tbx (83.6 KB)

2 Likes

That is neat too. Do you think this extra logic has more benefits? (just wondering)

Off the top of my head, @PaulWalters method seems a bit cleaner in separating form and function. Mine was really a hack.

I like @PaulWalters’ approach. I perhaps ought to revisit the docs. This approach harks back to the the original approach of ‘seeding’ attribute values. We then got suggested values which are good if you know in advance what the value set will be and/or the values change infrequently and/or you want a form of controlled vocabulary (i.e. only picking from (pre-)listed values). Once again, no one right way!

A tangential upside of using per-value notes is these can generated easily for imported data (or accrued data in the TBX). We can collect existing values, make that list the $Text of a note (single value/list item per paragraph), explode the $Text to new notes, apply the new notes’ $Name to our desired attribute. I further upside, which I use often in my research is then to link that note to all notes using the value, e.g. linking per-author notes to papers where they are an author. I tend to use stamps or edicts rather than agents, but that’s personal taste.

1 Like

Not sure how to answer that. A complex file can benefit from self-documentation and traceability.

1 Like

I can confirm. I’m using it in a TBX i’m building on photobooks, and I’ve added a “Set Collector” section close to my “Prototypes” section. I get lists of photographers, authors, reference books self populated. And when i get back to it next time, it is nicely self documented.

1 Like