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

2 Likes

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)

4 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

I found this thread in my search to figure out if there is a way to programmatically populate a set of suggested values for an attribute. In my case, Iā€™d like to populate a suggested list of an attribute based on the names of all the children in a separate container.

This ā€œhackā€ is an elegant alternative. Iā€™ll simply set a prototype for the children in my separate container that makes $MyAttribute = $Name. VoilĆ ! Many thanks.