How to get the elements of a set-type Displayed Attribute?

Q & A - getting started with Tinderbox
1

Seems a simple question, but I find no answer and would be grateful for a hint.
I have a Displayed Attribute $Section that is of type set. How can I get the elements of $Section turned, say, into individual notes? Any ideas?

2

Wading deep for me here lol - but I would create a Note, collect the elements of $Section (and/or other constraints) - while separating each by a delimiter of your choice, drop the result of that collect into the $Text field, then Explode (on your delimiter).

3

Thanks, Art! Let me explain in a bit more detail what I need this for.
I am collecting academic articles on a subject and try to come up with a classification for the subject area.
So I created adornments, which put their $Name into the $Section DA of any notes I drag onto it.
The above happens in Map view. In a different part of the Tinderbox file I want to collect (in Outline view) aliases of the notes ordered by $Section - i.e. I want to create agents from the elements of $Section, with a query that collects those notes which have the respective $Name in $Section.
Still with me? I‘m afraid I‘ve probably confused everyone now… But any suggestions with concrete code ideas are highly welcome!

4

I think that is easier - create an Agent that collects any Notes where $Section!="" - then sort that Agent by $Section in Outline View.

5

How can I get the elements of $Section turned, say, into individual notes?

I expect you want something like:

$Section.each(x) {
       create(x);
      }
6

Looks intriguing - but where would I put that code? It seems to look like a function, but if that is correct, where would I call it from? Thanks for your help!

By the way, for the time being, I decided to solve my problem manually. There are only 14 elements in the set, so I copied each element once and put them in an agent with the query e.g.

$Section==“Regulating privacy”;

and named the agent with a rule / edict stating

$Name(agent)=$Section(child);

But in principle I am still interested to solve the problem of automatically reading the elements of the $Section set and transforming them into notes named after the respective element. So keep the solution suggestions coming!

7

To get the Sections:

$MyList = values("Section");

Now iterate to create agents:

$MyList.each(aSectionName) {
       create("/path/to/folder/"+aSectionSection);
};

See how it works, here: Section-test.tbx (83.2 KB)

1 Like
8

It is action code, so you can put it wherever action code works:

  1. Stamp
  2. Action
  3. Edict
  4. Fuction
  5. Link actions
    6…other places

I would start with a stamp.

1 Like
9

Many thanks, Mark, especially for the example file which made it all clearer. My first encounter with the “values” and “create” operators…
This will allow me to have Tinderbox dynamically reorder my notes (i.e. academic references to be taken into account for that section) when I decide to change the elements of $Section. Will be very practical when I get it to work!

1 Like
10

BTW, there are all in the linking demo for your journal work I sent to you a while back. Now that you know what to look for, those demos may be more helpful.

They are also outlined in detail in the linking training videos: Tinderbox Training Video 62- Dynamically create notes from attributes with functions

11

Thanks for the information, Michael! That video is one I actually downloaded so I can access it anytime; I’ll check it again for these aspects. Much appreciated! I didn’t see the link (no pun intended) between the two uses, but now that you mention them they’re obvious.

1 Like
12

Mark - thanks again. This was really helpful.
I found that in the last line of the stamp the following is even better, because it allows several elements in the set to be present and found:

$AgentQuery(vResultPath) = '$Section.contains("'+aSectionName+'")';

One more question: if one of the elements as a “/” in it (such as in “Intro / Overview”), then that is taken as indication of a subdirectory in the way the vPath variable is constructed. Can you think of a way to avoid that? It results in unnecessary container construction (as in “…path/Intro/Overview”) which is not terrible but inconvenient. The (equally inconvenient) alternative would be to forego using the slash in the elements of $Section…

1 Like
13

If I understand this is a question of ‘unsafe’ note titles, see my notes here. This is a known problem and there is no formal documentation on how to approach this, though the concept seems to be don’t use problematic characters and you won’t have a problem. But, as you point out, sometimes a note title needs to contain such a character.

Possible approachs:

  • Just avoid using problematic characters. But:
    • not really a practical solution for many users.
  • Store the ‘real’ title in in a user String attribute and amend the note title to remove or substitute ‘bad’ characters. A Display Expression can be used to make the note title look like the desired title. But:
    • get complex if exporting as the user now has to track when to substitute the ‘real’ title for the hacked one.
    • less problematic is re-titled notes are branches (i.e.not containers). If containers, there may be additional issues if wanting to recover title into from path segments as the path will contained the hacked title not the real one.
  • use $ID to specify offset references, i.e. attributes in other notes. But:
    • It appears some action operators still fail using ID references as the bad characters in the path/name bleed through somehow.
    • It is a pain having to look up $ID of a string title you can otherwise bring easily to mind.

So, there is no ideal fix. Currently, your options are to pick one of more of the above list. I think using $ID is the best way ahead butfor reliability it will require re-validation (testing) of a lot of action operators and I’m uncertain how that task is/will be addressed. If action code can be made to correctly use $ID where $Name or $Path are otherwise used, then problematic $Name values should be less of an issue. There is a further, as-yet not accepted, issue where Tinderbox appears to apply unwanted type coercions treating $ID values as the wrong data type causing a silent fail.

Is this all a pain? Yes! But you are not alone, others are also raising this and seeking clearer guidance beyond not using certain characters in note titles. I’d like to give clearer advice but the problem is internal to the app. Thus, as users, we can only annotate what breaks but not, with any confidence, why.

1 Like