"Dynamic" Agent Queries

I’m trying to run a query that depends on the value of an attribute (which is a set, so itself can contain a few values), but the agent won’t pick up any aliases.

Details:
In the agent aGatherExpert the attribute $Experts contains the set [Smith, Duncan].
I want the agent to gather aliases of the notes for the experts whose last names are Smith and Duncan (prototype name is Expert).
The following query works:
"Smith, Duncan".contains($LastName) & Prototype=="Expert";
But these don’t:
$Experts.contains($LastName) & $Prototype=="Expert";
$Experts.contains($LastName(that))) & $Prototype=="Expert";
even though the attribute $Experts contains the set [Smith, Duncan].

I’m probably referencing $Experts wrongly, but I can’t see how?

Where are you defining (i.e., assigning values to) $Experts and where are you defining $LastName. Inside a note? In the prototype?

It’s not clear from the description how these attributes come about, and what the scope (what notes or container) the agent query is looking at?

Can you post here a little example of the file you want the agent to work in? It’s more helpful than us guessing at our own examples and not understanding the context.


Update: OK, I’ll take a guess at what your file is doing, and the agent works in this attached file. What I did was define $Experts and the content of the data set in $Experts, in the Expert prototype. See the attached.

(A side note, defining attributes, note names, and prototypes with similar names can lead to confusion. Not a bad thing, just easy to make mistakes.)

Experts Agent 20200306.tbx (92.9 KB)

2 Likes

… also, other options for setting $Experts would be in the user attributes inspector (set the default), or in another note which would be referenced as $Experts("SomeNote")

Actually, if you are trying to test the contents of a list (List or Set type data), then the string you weant to test should be a smei-colon-joined set of values:

"Smith;Duncan".contains($LastName) & $Prototype=="Expert";

Separately and although it does no harm, whilst agent queries are written in action code they should not include a semi-colon at the en d as in a normal action code expression. Luckily, if you make that mistake, Tinderbox ignores the error, though it is an error—i.e. try to avoid it.

However, these aren’t the problem with you agents. This:

$Experts.contains($LastName) & $Prototype=="Expert"

Is testing each note’s $Experts against its $LastName. Assuming you are trying to test export names stored in the agent’s $Experts, the query would be this:

$Experts(agent).contains($LastName) & Prototype=="Expert"

Note the use of the ‘agent’ designator in the first part of the query. This method allows you to alter the agent query simply by altering the values for the agent’s $Experts attribute. This is easily done if $Experts is added to the agent’s Key Attributes.

This is a different solution to the one above, and a good example of how Tinderbox offers multiple routes to a solution. Both work, only you can judge what suits best.

To make it easy to play with both examples, I have modified the above file (and its filename). Before adding a link, here are the changes:

  • I’ve given the prototype a $Color and a $Badge value so it is easier to see which notes use a prototype.
  • I’ve moved the test cases into a container ‘People’
  • I’ve added some non-export people inlcuding one with a $LastName that would match the $Xperts test but fails the $Prototype one.
  • I added a second agent using the logic described above.

Here’s the file (kudos for the original demo concept goes to @PaulWalters): Experts Agent 20200306a.tbx (105.2 KB)

1 Like

FWIW, I wonder if & $Prototype=="Expert" is superfluous? Unless there are some other notes that use the $Experts attribute and that do not have the “Expert” prototype, then the query term is not needed.

Doesn’t that need to be ...$Prototype... rather than ...Prototype...?

Fixed the $ typo - thanks - and added an important bullet I’d forgotten re the extra agent.

Superfluous use of the prototype query? In my agent (‘Exports Agent 2’), try removing the $Prototype test and the non-Export note ‘Agnes Duncan’ is matched althuogh that’s not our intent.

I’d started answering before being called to a meeting, returning to see your answer. I think your solution is neater, but I think the answer I gave is closer to what the OP had been attempting to do. So the answer issn’t in opposition but just trying to help explain why the previous tests had gone wrong. :slight_smile:

1 Like

Thanks @PaulWalters and @mwra for your prompt replies, and apologies for letting you guess my intent. I had a smallish minimal working examples that I forgot to include.
The intent was in effect that the list reside in the agent, as in the second example.

I had tried to put (this) and (that) on the $LastName property, completely forgetting to try (agent) on $Experts. In another thread @mwra told me to think in terms of Rolodexes and attributes being filled and checked on every single card. I should have embraced that more.
@PaulWalters, your point about naming things with similar names is well taken. Thanks.

The $Prototype condition was useful because I have other “Person” based prototypes which have last names, and which I don’t want to see in this particular gathering. But if I didn’t have that issue, than yes, I don’t need to filter anymore.

Again, my thanks!

1 Like

Hi Paul

If you do not mind, can you post your final solution that worked. I am exploring a similar issue.

Many thanks
Tom

I will as soon as I’m back at my desk. In the meantime @mwra ‘s solution is a minimal working example

Hi, sorry it took a while. Here’s a stripped down version of my tbx file. The note in red contains the agent that gathers aliases of people I list in the note itself. HTH
agent query test.tbx (153.9 KB)

1 Like