Action code in Attribute Browser

(eastgate) #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.

(Pat Maddox) #22

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

What is the challenge with multiple selections?

(Paul Walters) #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.

(Rene Trappel) #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.)

(James Fallows) #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.)