Conditional display of attributes

Q & A - getting started with Tinderbox
1

I seem to remember that this has been discussed before, but I can’t locate the corresponding topic – apols.

Here’s the scenario:
Some of my prototypes have a good number of attributes displayed. However, not all of these are relevant for all notes created for that prototype subsequently. For example, notes on films will typically have a $TimeCode and be linked to a video file ($vURL), whereas for notes on books or articles neither of these make sense and they tend to get in the way if they are displayed.
How would I hide irrelevant or unused attributes if these are shown in the prototype? Or would it be easier to start with an empty attributes table and choose which ones to display? I presume there are at least the following two steps involved:

  1. Formulate the condition for showing/hiding the attribute,
  2. Tell Tinderbox which attributes to show/hide.

Any help would be much appreciated.

2

Would it make sense to have separate prototypes for Books and for Films? Perhaps each inheriting from a common ancestor, Sources, but differing in displayed attributes?

3

Great suggestion, Mark, and so simple :wink: . The more general question remains, however: is there a way of formulating conditions for the display of attributes?

4

In principle, an agent (or a rule or edict) could modify $DisplayedAttributes. For example:

if($Director!="") { $DisplayedAttributes += "Director;Producer;";}

This would add extra displayed attributes if the source has a director.

5

It’s worth noting it would also break inheritance from any prototype in use. That doesn’t invalidate the code above, but beware if using it in context with prototype.

There is a further issue. Displayed Attributes’s predecessor $KeyAttributes was a Set, but $DisplayedAttributes is a List so the above code has the consequence that every time a rule or edict runs the two attributes are re-added. To avoid that use:

if($Director!=""){
    if(!$DisplayedAttributes.contains("Director")){
        $DisplayedAttributes += "Director;Producer;";
    }
}
6

You could also switch out $Prototypes via a Rule/Agent depending on your specific usage or point within your project; the two Prototypes can be identical except for their $DisplayedAttributes value.

I sometimes like to know the status of all Attributes in a set of Notes - even the information that a field is blank can be critically important. Swapping between 2 Prototypes will allow concurrent use of “long Attribute list” vs. “essential Attributes list” views, for example.

1 Like
7

I’ve tried to get this example working but it doesn’t seem to fire. Please see the attached file. Note 1 is simply to create the attributes and put some values in them. Note 2 has the rule that you suggested, that I can’t get to work. Note 3 has @eastgate 's example code, which, as you correctly predicted, causes a proliferation of displayed attributes. How can I get it to work correctly? Thanks.
Conditional Display of Attributes Test.tbx (98.3 KB)

8

Note 3 fails because $DisplayedAttributes is a List-type attribute. For much of Tinderbox’s life it was a Set-type, where that code would work as a Set-de-duplicates entries. However, in recent years Sets (for other good reasons) auto-sorts its values in A–Z order. But, this not generally the order we want in Displayed Attributes. So Note 3’s rule is a bust.

Note 2 does work, as intended, in your demo. Select Note 2 and open the Displayed Attributes configuration pop-up and click the ‘reset’ button, so all Displayed Attributes are removed. The moment the note’s rule next runs the two expected attributes are added back.

Or if I make a new note with no Displayed Attributes and give it a value for $Director and give it Note 2’s rule, the Displayed Attributes add attributes ‘Director’ and ‘Producer’. If I do the same but with a new note that already has some Displayed Attributes, the attributes ‘Director’ and ‘Producer’ are added to the existing Displayed Attributes. That is what the code expects to achieve. Perhaps expect it to something else, in which case you don’t say what that is.

Note 3’s failure helps explain Note 2’s code. As $DisplayedAttributes is List-type, re-adding an existing an already-listed attribute to Displayed Attributes will mean that attribute is listed twice in Displayed Attributes. Or, as in Note 3, another instance is added every time the rule runs. Note 2’s rule ensures ‘Director’ is only added to ‘DisplayedAttributes’ _if not already displayed’.

So please give step-by-step instructions on how to cause the rule to fail when editing $Director.

N.B. Note 2’s code only adds attributes. If the value of $Director is subsequently deleted, the rule does not remove 2 items from Displayed Attributes. That likely could be coded for but is currently out of scope of the task defined.

9

Thanks. Not sure I fully understand it but it’s working as you said, after hitting reset. Why is that the case? I’m trying to understand the algorithms better. Could there be a line of action code that we could append at the tail end of the rule, that would reset the displayed attributes, thus avoiding having to do so manually? Thanks.

10

Could be something like $DisplayedAttributes=;, but if you have it in the rule you’re added unnecessary triggers. It only needs to be done once

11

Noted. Thank you.

12

That button does the same as the code @satikusala gives just above. But consider this line in the original rule:

 if(!$DisplayedAttributes.contains("Director")){

That test: “Do the Displayed Attributes currently include the attribute 'Director?”. OR, more literally, “does the list of values of attribute $DisplayedAttributes contains a value of ‘Director’?”

So for instance if when testing you’d added (by whatever means) the Displayed Attribute ‘Director’ but not ‘Producer’, the above if statement would be true so the code would not run.