OK, let’s say you’ve 10 attributes at present for which currently you build an agent for each. Now you could:
- create 10 per-attribute AB views and save them to the document’s gallery. Once created/saved you can close tabs and re-add them as necessary:
- Tabs in the background don’t run any code so having a tab open but not current has no overhead.
- or, create one AB view and simply change the target attribute. IOW, one AB view can show you all 10 attribute’s data—just not all at once.
Note that there is no simple mechanism to to ‘just’ copy a (saved) tab from one TBX to abother but there are a number of workarounds for that. If needed, best addressed when needed to avoid a small essay here.
The basics of AB view are its scope and its target attribute. By default, scope is the whole document but can be any single container (and descendants ). In addition, the selected containers contents/descendants can be modified by an agent (defined in the AB view), e.g. to filter only those notes using a particular prototype.
The user-selected attribute dictates how the main view contents are displayed. Whilst scope selects which notes are listed, attribute selects what is shown for each note and the order of listing. There are lots of customisations which are all explained in this section of aTbRef; as that’s easily looked up, I wont’ go into it here.
Once you’ve tried AB view out I think you’ll find your per-attribute agents, whilst working, are a more cumbersome approach. One upside of the AB view approach—where it is pertinent—is fewer agents running for no loss of access to information.