Code to exclude nested container?


(Tom Diaz) #1

Hi

I have a note with client information and have nested my agents neatly in a container inside of the client note/container.
The issue is: I have set up my agents and they easily work using descendedFrom(/MyClient) however descendedFrom also looks inside the nested container. I would like to use a descriptor like inside(parent) or inside(grandparent) just to only use the children of /MyClient.

For clarification: here is my structure
/MyClient
/MyClient/Meta — this is the folder I do not want my agent to search.

I have used descendedFrom(/MyClient)&$Name(“myRegexExpression”): works
inside(parent)&$Name(“myRegexExpression”): does not work

Thanks in advance?
Tom


(Paul Walters) #2

The simplest solution would be to move Meta from /MyClient/Meta to /Meta – i.e., make it a sibling of MyClient.

It seems from your description that your agent is searching its parents and/or its siblings – which could lead to looping code and (as you discovered) unexpected results.

Personally, I always place agents outside of the hierarchy that they search.


(Tom Diaz) #3

Thank you Paul as always.

That works. Do you know how I can automate this for changing clients? How can I change the name of the Client container and still have the agents run. I am thinking that descendants would be perfect however, inside(sibling) does not work. Although I can change the value of the container to be analyzed, is there a way to automate this. For some background: I created a prototype called pClient with a nested folder (original post) post using descendants did not work. The one I am most familiar with is inside(parent) and inside(grandparent) did not work for the structure /Client and /Client/Meta

If I use the structure below: any thoughts on how I can automate my agents in /Meta to work on /Clients if they change names. NB: its almost like I need a variable but I do not know how to do this other than using the descendants paradigm.

/Client
/Meta agents

Thanks again for your efforts to help me.
Tom


(Paul Walters) #4

One way is not the change the container’s $Name – leave it as “Client” – just the appearance of the container. Use $DisplayExpression.

This little file is an example.

Stealth.tbx (55.8 KB)


(Tom Diaz) #5

Humm… great idea. I had not thought about this solution. That would certainly work.

Thanks again.
Tom


(Mark Anderson) #6

inside() relates to direct children of a container, whereas descendedFrom() covers all descendants. In both cases an alias of a note, whose original is not otherwise within scope of the agent’s query, will still match. This is a common unwitting source of apparently malfunctioning queries as the user has overlooked the effect of aliases. Using a query &$IsAlias==false will filter out aliases as potential matches.

Separately, one way to configure per-client agents set up via prototypes with bequeathed contents is to use an edict (or stamp) to set the per-client data, e.g. a $Name, $Path, etc., stored that in a string attribute in the agent and use the ‘agent’ designator to call that in the agent query. For example descendedFrom($MyString(agent)).

Also, if using per-project ‘meta’ containers consider putting all the other project content in a sibling folder:

/Project X
          /Meta
          /Notes
/Project Y
          /Meta
          /Notes

This way the desired content is in a sibling container and the likelihood of mis-identifying the correct target is lessened.


(Tom Diaz) #7

Thanks Mark for your comments as well.

Question:

With my structure being the following:
/MyClient
/MyClient/Meta — this is the folder I do not want my agent to search.

I would much prefer to use a designator like: inside(parent) but the designator “parent” does not work with inside(). Why?

Ex
descendedFrom(/MyClient)&$Name(“myRegexExpression”): works
inside(parent)&$Name(“myRegexExpression”): does not work

Thanks
Tom


(Mark Anderson) #8

In which container is the agent, as it’s not clear for your last? Even better build a minimal demo TBX and upload it as if regex are part of your query we likely want to exclude those as contributory factors. You variant that works could be a false positive.

Also why to you not want to use descendedFrom() it it works - is there some other unrevealed factor to the problem?


(Tom Diaz) #9

Thanks Mark,

I have included an example of my structure. For clients I like to separate Data from Meta for each client, hence I would like to keep this structure.

Here are my thoughts:
With my limited knowledge of scripting,

  1. I would like to use designators ,in this case: (grandparent): so that I can automate the scripting for multiple different “clientNames”.
  2. I would like to use inside(grandparent) only because it avoids a looping issue since my agents are embedded in a subfolder. Why does descendedFrom(grandparent) work and inside(grandparent) not work? This is where I am stuck?

Thanks
Tom
InsideTest.tbx (80.3 KB)


(Mark Anderson) #10

Step one, I’ve rolled back all sorts of rules, etc., that doesn’t reflect the task including reinitialising some actions (e.g. $OnAdd) set at doc level. My experience is that it is rarely never a good idea to set doc level default action codes.

So here’s the ‘cleaned’ doc: InsideTest1.tbx (76.0 KB)

Note that as your root container for all client info is called Data, I’ve called the per-client ‘data’ container ‘ClientData’.

Please don’t misread any of the changes as censure, it’s just that all sorts of weird stuff was happening in the doc you sent so I’ve tried to create a less dynamic references TBX, if only for anyone else here playing along at home. :grinning:

More to follow…


(Mark Anderson) #11

Before I forget, your original ‘insideAgent’ fails because it is looking inside, i.e. at the children only, of its parent container. IOW, it’s looking at the wrong container!

OK try this: InsideTest2.tbx (82.9 KB)

Take it from me, pre-deploying agent as bequeathed via prototypes is an exercise in masochism. Better, make a container that configures your agents with necessary data as you add them. This is what I’ve done…

So what’s changed:

  • I’ve added a $ClientDataContainer which is intended to to hold, for the ‘meta’ container, the path to the sibling ‘ClientData’ container.
  • As Tinderbox (as yet) lacks a method (via menu or shortcut) to add an agent as a child of the current selection, i’ve added a ‘Blank’ note to the ‘Meta’ container. It’s only purpose is to ensure the (first) agent added is that sibling of a child of ‘Meta’.
  • Now, you select ‘Blank’ and then add an agent, whose query is: inside($ClientDataPath(agent)) and you should get the right (client’s) data each time.

(Tom Diaz) #12

This is awesome Mark. Thank you for taking the time to go through the concepts of configuration notes and discuss the best practice of using them. To be honest, this project became a bit “out of reach” for my skills but this is helping me extend my boundaries a bit. You are right there, were rules in there there that related to a more global “commonplace” tbx. I tried to clean this up to upload as an example case.

Questions:

“I’ve rolled back all sorts of rules, etc., that doesn’t reflect the task including reinitialising some actions (e.g. $OnAdd) set at doc level. My experience is that it is rarely never a good idea to set doc level default action codes.”

  1. How can I easily find them? I suspect the attribute browser would be ideal?
  2. What do you mean by “doc level default action codes”?

“Take it from me, pre-deploying agent as bequeathed via prototypes is an exercise in masochism”

  1. I suspect this relates to my original approach to attempt to create a “generic” prototype using designators, correct? I am interpreting that this is ideal for the use of configuration notes, correct?

As always, many thanks,
Tom


(Mark Anderson) #13

#1. Well, I forget now which attribute it was - possibly $OnAdd - where you’d set a document level_ custom default value. Doc level defaults can be seen via the System tab of the Documents selector. There is no single mechanism to detect/report such customisations. Whilst there is a rationale for changing doc-level defaults for some attributes like NeverComposite or $SmartQuotes these (a) tend to be Booleans and the effects are generally easy to spot by eye. But for actions, I’d say ‘No’ in general. The day you find a real need to break that you’ll have a good reason and an understanding of that reason that will render my warning defunct. TL;DR don’t make such changes until more familiar with the app. For action-based attributes, I’d say prototypes are a much better approach for seeding action-based code.

#2. See here.

If you’ve been fiddling with a lot of system defaults - or other settings _ and can’t remember what you’ve done, I’d archive the file and start over. You can always copy over the actual ‘content’ notes as like as not these just inherit attribute values set elsewhere.

#3. Pre-configured structure. Given that part of Tinderbox’s strength is to add structure as you need it, building pre-configured nested containers with actions seems to run counter to that convenience. Ask yourself if you’re pre-making all the structure because you really need all or it for each project/client and you’re adding new projects/clients every few minutes. Or, are you pre-making structure because that’s what other less flexible apps have forced you to do in the past? Better to make a set of prototypes that can be used with(in) one another as needed.


(Tom Diaz) #14

Thanks Mark.

Great advice. Simplify and add structure as needed. I will archive and start over.

Many Thanks
Tom