Changing DisplayExpression based on attributes

Q & A - getting started with Tinderbox
1

I’m attempting to use $DisplayExpression to show me more information in the name of a note. Currently a note is evaluated by an agent to see if it has a $DueDate and/or $ContextTag. Depending on which it has depends on what is displayed with the $DisplayExpression. My current agent code is:

if($DueDate&$ContextTag){$DisplayExpression=‘“[”+$ContextTag+"] “+date($DueDate).format(“W, d MM y”)+” | "+$Name’}else{if($DueDate&!$ContextTag){$DisplayExpression=‘date($DueDate).format(“W, d MM y”)+" | "+$Name’}else{if($DueDate==“never”&$ContextTag){$DisplayExpression=‘“[”+$ContextTag+"] "+$Name’}else{$DisplayExpression=;}}}

This works as follows:
If the note $Name is “Speak to Harold about widget X” and has no $DueDate or $ContextTag the $DisplayExpression shows:

Speak to Harold about widget X

If the note has only a $DueDate the note $DisplayExpression:

Friday, 24 February 2017 | Speak to Harold about widget X

If the note has only a $ContextTag the note $DisplayExpression:

[call] Speak to Harold about widget X

If the note has both a $DueDate and $ContextTag the note $DisplayExpression:

[call] Friday, 24 February 2017 | Speak to Harold about widget X

I’m realizing that this can be extremely useful and want to employ it for more attributes. However, the more attributes, the more permutations of combinations of attributes, making the action almost impossible to code.

Is there a simple way to do this? Can I set a agent to work out which attributes are not empty and automatically add them to the $DisplayExpression?

You may ask, “what’s the point?”, can’t you just look at the attributes? My reasoning is that I have a long list of projects, tasks, meetings and events. For projects I want to see the task count, for tasks I want to see the due date and context, for meetings I want to see the due date and who’s responsible for the meeting. If I could manipulate the display expression to be smart, these various pieces of information would be displayed in the list reducing the need to click on each note.

2

Actually, I’d ask “why not use Attribute View, or use columns in Outline view” – Attribute View is an excellent tool for tracking “projects, tasks, meetings, and events”. Plus – $DisplayExpression has to be evaluated for every note all the time – it places a computational burden on your machine that can grow to a noticeable level.

3

Here’s an approach that should be far cleaner.

  1. Make three prototype notes: SimpleTask, DatedTask, and DatedTaskWithContext. Each prototype has its own $DisplayExpression, which instances will inherit.

  2. Use your agent to assign the appropriate prototype to each task.

Don’t want to do this with prototypes? Perhaps you’d already using Prototype differently. No problem!

  1. Make three notes, Simple, Dated, and DatedContext, each with its own $DisplayExpression. Tuck all three insider a container named /config.

  2. Use your agent to copy the $DisplayExpression.

if ($DueDate&$ContextTag) {$DisplayExpression=$DisplayExpression(/config/DatedContext)} …

Either is simpler, easier to understand, and easier to improve later.

4

Although I like the attribute browser, I rarely use it. The main reason is knowing where the attributes are that you want to view. I also cannot seem to figure out how to use it to display what I want. ie, view due date by projects and so on.

Saved searches would be simpler.

5

Many thanks, I shall work through this.

Is it preferable to have more prototypes and less agents? Does that lessen the computational load?

6

It’s not a question of more prototypes or fewer agents; I think my designs have the same number of agents.

Constructing expressions is harder than copying expressions.

7

True, but in the case shown these are mainly User attributes (custom to you) and so they are in the User group.

You mean agents?