I have a container with some notes. Is it possible to show only the names of unique values for an Attribute in the Summary Table using an expression?
No and Yes. Is there button to ‘just’ do this? No.
Could you do this with action code, possibly Yes.
But your proposition is ambiguously stated. A table expression reports on the children of the note, but your question implies you want to list all discrete values of a given attribute. What if they occur outside that container. What is the actual intent here?
Also consider the fact that 5–10 values will work fine but in a mature document the list might be 10s or 100s which might mot fi on screen (summary tables don’t scroll).
Yes, show discrete values for one attribute of the child notes.
Note 1 - Attribute A - Value Alpha
Note 2 - Attribute A - Value Bravo
Note 3 - Attribute A - Value Charlie
Note 4 - Attribute A - Value Bravo
Note 5 - Attribute A - Value Alpha
HTH explain the ask. If not, let me know.
Sure, there are countless ways to do this.
See the HTML Page template. I included the following action code:
var:set vSet; vSet=collect(children,$AttributeA); vSet=vSet.replace(";","<br>");
You then pass the set value to the body with the ^value()^ export code.
Again, there are so many different variations and paths you could go with this. Which variation and path you choose ultimately depends on why and when you need this. Note, the above action code could easily be placed in a stamp, $Rule, or $Edict, as well.
TBX L - Collect Attribute Value from Children.tbx (139.9 KB)
The most common pattern for surfacing values is to use values(). By default it returns all discrete values† for an argument specified attribute. An optional second argument lets you specify a scope as the default is the whole document.
So, values() returns a Set: a lexically sorted list, de-duped (but case sensitive—‘Ant’ and ‘ant’ are discrete values). That list can made into a value-per-line $Text for review or the text can be exploded into notes. Easier, now we have—since v8—the create() operator, so we can iterate the values() derived list and make a new note per source value.
You do that using the Summary Display Properties pop-over. For instance:
Here, we’ve configured 4 columns (each row above is a column in the display). The first 3 columns use attribute values, the fourth column shows that the displayed value can be the result of an action code expression (ideally not a complex one‡).
Tip: You can’t place the pop-over’s table cells in edit mode using a cursor click, you must use the Return key. Odd, given you that can’t open the dialog using a key. It’s just one of those quirks. (One I ought to record in aTbRef as it trips me up every time I infrequently use this feature.)
The limited range of table visualisation (colour, font, etc.) is described here: if you want to style the table, I’d use @satikusala’s export-based approach above (you don’t actually export, but you construct the view as if you were).
Here’s the file for above: table-demo.tbx (156.7 KB)
As I know (separate conversation) your referenced subject matter is large, I think you’ll find that container summary tables will scale badly. If you are looking to chart values of notes in the container, don’t overlook container plots.
For the learning stage with the app, my advice would be to read through the section on aTbRef on views and for the view types of interest read all the notes there. If asking yourself, “how do I…?” or “can I…?”., then do as above. Make a small TBX, as I just posted, with just enough content to allow you test that feature. In truth it’s a far quicker way of seeing “does it?” and if still stuck it generates a more bounded question for the forum.
†. For multi-value attributes (List, Set) each note’s lost of values is passed into discrete values.
‡. There’s no limit as such but common sense applies.
@satikusala Thank you for the sample file and the great information!
I watched your video and knew of some of these approaches. However, I was exploring how to display the unique values in the Container’s Summary Table. So, I wondered if this could be done using Expression value only without a layered solution.
Next time I’ll start with an image like the one below for my post. I thought terms like “Summary Table Expression” would lead everyone to exactly where and what I was doing, but that didn’t happen.
@mwra Thanks for the fantastic details and numerous references as well! I was working on a response to post from @satikusala when yours came in.
This tripped me us in the beginning as well, but I found a right-click on the text in the Heading or Expression column works as well. So many ways to get there in Tinderbox. Maybe another point for the documentation.
As I stated above, this is what I have been doing but wasn’t able to display the unique values as @satikusala did in his report. Essentially, can that output be displayed in the Container’s Summary Table via expression? If I missed something that gives this answer explicitly let me know.
Attribute A (This is the heading)
Value Alpha (only shown once even though there are two notes in my example)
Value Bravo (only shown once even though there are two notes in my example)
Also, I appreciate the thoughts and advice around scalability.
I think we got out of sync on ‘unique’. I’d interpreted that as a single instance only at output. Here, I’ve adjusted one of the $MyString values in my earlier demo to show the point:
Notes “cow” and “dog” have discrete ‘unique’ values, but seen across the values() set of all $MyString values, there are 6 notes with a value for the “MyString” attribute but only 5 unique values. Scope for unintentional confusion.
On reflection, my aTbRef illustration is perhaps unintentionally misleading for a new reader as it might imply the table as a mechanism for rich reporting. The little demo file actually gives a truer reflection as to purpose—summary!
As the table lists all children† and can’t be filtered. IOW, you can’t control so as to show only the first 5 of N children. You can essentially hide some items by dragging the title/viewport splitter:
Note: doing this you are actually altering $TitleHeight. See more here: Container title height.
another thought re scalability. If you know, due to your contingent research/work information (which varies for each of us), that your number of notes won’t be in the low tens, then when trying out features, ask your self “Now I know how feature X works, would it be useful for 100 items as opposed to 10 items?”. Either way, I think one needs to start by trying a given feature as only once we see how it works can we sensibly ask, “Does it work for *my data?”. This is where one-size-fits-all answers are difficult (and unintentionally misleading).
†. Regardless of whether they themselves have children. IOW, a scope of
children and not
descendants. This is because we are in the single container scope of a map, albeit reporting the child map of the selected container.
OK, while I remember to do it…
The article on Summary Display Properties pop-over is now updated to reflect the issue of key vs. cursor use for selection/input.
Yes, I was using unique as related to unique values in a data set versus your use of discrete or distinct rows for the table. I want to get the unique values in the data set of all the children’s notes in the container without additional layers/steps. e.g., separately building a list/array and getting unique values. Like I said earlier, @satikusala hit the output requirements on the head, except where the output is displayed. So it seems like this last response infers that the answer is no.
Yes, I noticed this through experimentation yesterday. For example, the Table Summary doesn’t work well broadly when there are 1800 notes in a container. Not very useful without scroll or large map area. Thus, I thought of learning how to apply filters or get “unique” values as I described above to provide scaleable value. I posted what I thought would be a quick yes or no question, but life sometimes takes you down unexpected paths, especially when communication is involved.
This approach is what I have been doing—small tactical projects to explore specific functionality in Tinderbox. First, learn the “Art of the possible,” then assess what I can put in my toolkit and how to apply them to my projects. Admittedly, I’m also effectively doing a pressure test as part of this process.
Ah, yes. Clearly, you caught some of my myopia, as I don’t use summary tabs I kinda glossed over that part of of your request. Thank for the reminder to be more present.
No, my fault, based on some poor assumptions. Next time, I’ll include a picture.
Thanks. The main clarification (for me too) is that ‘summary’ may be misleading here. Rather it is a really more like an outline+column view of the children albeit with the following tweaks:
- the column head name need not be the source attribute name
- the column value can be an action code expression and not just the literal value.
But, the scope of the table is fixed as (all) immediate children of the container and there is no filtering.
Table items are listed in $Sort order
Welcome, I just took that from the inspector “Summary Table Properties” and assumed it was obvious. Turned out, it wasn’t.
I wanted to make sure my previous note made sense. You have to right-click directly on the placeholder text, so if you decided to leave it out because people might not easily understand it, that is fine. However, I wanted to make sure you didn’t miss it.
Thanks for the clarification. I didn’t mention it as I couldn’t get that to work. Also the row must be selected before you try to use-right click. Why? I don’t know, but years of beta testing have taught me that user’s intuition and developer’s intuition often don’t overlap. That’s not a slight at either party but a reflection that intuition is more subjective than we imagine and software—where the software can’t reasonably guess intent from input/context alone—shows this up.
Busy in other stuff now, but noted this for adding the the pop-over article IDC.
Meh - done. See Summary Display Properties pop-over.
I still think the input is over keyboard-centric. An overlooked aspect is that some people are very keyboard centric, others the reverse. All sorts of issues, not least disabilities, play into that. Designing for one, not both can result in confusion.
Before this recent exchange I’d already made a feature request for double-click on a cell (regardless of current row/cell selection or edit mode). That seems a far better match to general observed behaviour (though it might conflict with style guides). The logic is, double-click the thing with which you wish to interact // if a cell is currently in edit mode, close that edit and open the double-clicked one. That description is not to be disrespectful to the developer, who in this app puts a lot of unseen thought into the UI. However, I think because few of us fluidly both key-first and cursor-first its hard to remember the mode we don’t use. Testing should capture this assuming both behaviour types are testing. In a toolbox there are a lot of ‘tool’ combinations. Plus it’s hard to properly test a feature to which one has no personal attachment (as likely we test them how we imagined they are used (e.g. from initial rough design notes) as opposed to how they are actually used). No foul there, just the complexity of testing unexpectedly complex things.