Action code in Attribute Browser

Q & A - getting started with Tinderbox
21

What I had in mind for actions in Attribute Browser:

Let’s suppose that Attribute Browser let you create notes. Your view has a query — say $Prototype==“Dialect”. You select a note in some section of the attribute browser, and create a new note.

TROUBLE! As soon you the note is created, it fails to meet the query, and so it’s removed from the attribute browser view. That’s not good!

So, we need to adapt the note so that, at the very least, it satisfies the view’s query. In simple cases, be can do this automatically; here, we could probably figure out that, to satisfy the query, we need to set $Prototype. But what if the query were ($Price>100 & $Price < 200)? Should we set the price to 101? 199? All sorts of weird problems can crop up. Often, these involve esoteric queries that you might imagine would never crop up in real life. Alas, they do.

So, the action was invented to deal with this: you tell Tinderbox how to make new notes satisfy the query. The action exists, in this view, to prepare newly-created notes so they won’t vanish from the view.

But this was all in support of a trick that Profs. Marc and Jocelyn Nanard pulled off in their attribute browser-like system back in the 1990s. Suppose your attribute browser was exploring $Status, and you had bins for Critical, Important, Desirable and so forth. Select an Important note, and press return: Tinderbox would make a note right below the selected note, and then would set the $Status to match the status of that note’s attribute browser category. This is more feasible than doing the same thing for queries, because Attribute Browser categories are more limited. And it’s very clever.

Yet even here, I got tangled up in edge cases and complexity, and we needed Attribute Browser now, not next year. I turned off note creation to avoid both these headaches, and the only time the attribute browser action needed to be called in the original design was for new note creation.

So, that’s how we got where we are. It’s not malign, and not arbitrary — at least not from a design perspective. I’m happy to revisit.

Similarly, for multiple selections.

2 Likes
22

Thank you for that description of the challenges facing actions and creating notes in AB.

What is the challenge with multiple selections?

23

An additional problem with creating a note in Attribute Browser is “where does the note belong”? The AB is a flattened view across all containers. So does a note created in the AB belong to the root? A action could set $Container, but why?

AB is not broken, IMO. We have stamps, we can use them (better yet with multiple selection; workable with single). “Action” can be removed from AB and nothing would be lost.

1 Like
24

That is a very interesting thought process - and I agree, from this perspective it is much more feasible to just prevent the creation of a new note in the AB.

However, if we treat the AB as variant of an agent (with a slightly different design), having the ability to deploy action code in it seems to me like a great addition with little risks, or am I mistaken? Stamps are great if one is dealing with perhaps 20 notes in the AB. As soon as there are several hundred notes having some option to automatize the application of action code would speed up the process quite a bit. An example coming to mind is the addition of tags, codes etc. (I know, one could use a regular agent to do this. Yet, this would involve several more steps. Especially so, if one would like to repeat the process with another change.)

25

I agree. Obviously I don’t know the potential complexities involved in tuning AB to allow multiple selections. I assume that would be less complex that either (a) allowing new-note creation within AB, or (b) empowering full-scale Action code inside AB.

If that assumption is right, then I think there would be a lot of payoff, for a (comparatively?) smaller coding cost, in simply allowing multiple selections in the AB. In combination with (especially) Stamps, that would match much of the functionality of normal Action code in the AB.

(How? The Query part of a certain AB display could be as sophisticated and precise as a normal Agent – and then applying a Stamp to the results would have the same effect.)

FWIW.

1 Like
26

Did we ever get an answer to this? I’m working on something where AB’s action comes in super useful – I want to view my list of notes that match certain criteria, while creating new notes that will automatically join that list. So, AB and its action are perfect for this.

But I don’t see any way to actually create a note!

27

My understanding is you can’t. Not all view pane ‘views’ are equal in this regard. I follow your point, though I tend see AB view as more of a report, so not a place to create notes; I’d switch to another view. FWIW, you can create a note in treemap view but it’s not entirely clear where it will be added. I suspect it too was seen more of a displayed report than an annotation view like Map/Chart/Outline. I’m not saying it must be thus, but rather I think that’s where we are at present.

I do wonder, if I have an AB view scoped to part of the outline (i.e. content from nested folders), how does Tinderbox decide where the new note goes - in which in-scope folder?

28

Ah, I think it may just be a bug. Here’s what I’ve uncovered:

  1. Switch away from the AB tab and back to it
  2. Create Note is now available – and the note is placed in the Container selection
  3. As soon as you click on a note, the Create Note option goes away
  4. Go back to 1 to create a new note

edit: That said, I haven’t had any luck getting AB to actually run its action on newly-created notes. Not sure what’s going on here.

@eastgate do you happen to have an example of how to use AB action? I made my action `$Color = “red” and got nothing from it.

29

This is changing in the next release.