I would like an attribute - e.g. the EndDate attribute to dynamically update to today’s value. What I try to accomplish, is to have a timeline where some entity, like a jazz band or a person, is represented by a line from their start up until today - and EndDate updated as time goes by.
Is that possible?
There are two ways you might approach this, with an agent or an action (rule/edict).
First you will need a way to indicate a band that is no longer active, so the updating process knows now to alter that band’s data. So, add a user attribute, e.g. BandInactive, data type Boolean, default value false (unticked). For ease of querying control I’d also make a prototype 'pBand" and apply to all notes that represent a band.
Agent approach
With an agent you could find all notes that are active bands and update $EndDate to be today. So the $AgentQuery value is:
$Prototype=="pBand" & $BandInactive==false
IOW: "find all the notes with the ‘pBand’ prototype, that are also still active. The alias of each band matching the query has the agent’s action run on it. Now the $AgentAction code:
$EndDate = date("today");
When a band ceases, don’t forget to set its $BandInactive attribute to true (ticked). That ensures it no longer matches the agent query (q.v. the second query term). You might wish to set the agents priority to a low setting so the action is running unnecessarily often.
Action approach
We could use a rule ($Rule) or an edict ($Edict). Rules run all the time and edicts run, at worst, once an hour. As we only need to update the $EndDate once a day, an edict is the sensible choice. Edict code:
if($BandInactive==false){
$EndDate = date("today");
};
When a band ceases, don’t forget to set its $BandInactive attribute to true (ticked). That ensures it no longer matches the if() operator’s conditional query (q.v. the first query term).
Notes
Originally, I thought to check also if the $EndDate was yesterday, as we update it every day. But what happens at weekends, or if the doc is closed while you are away on holiday. Using the Boolean makes sure we only process ‘live’ bands.
Note that all agents and edicts run when a document is open, so if you close the doc when not in use, it will always be updated on opening. Otherwise an agent will run at the periodicity you set and an edict c. once an hour. If you use File menu ▸ Update All Agents, it runs all agents (except those explicitly turned off) and all edicts.
1 Like
A point to note is that the user Boolean doesn’t need to be called ‘BandInactive’. You can use any valid attribute name instead. But, if you do, make sure you also change the attribute name in all the example code above.
A tip on naming Booleans. A name starting ‘Is’, Has’ or ‘Not’ is a useful as a prompt that the attribute is a Boolean and as to its purpose—though don’t overlook giving your user attributes a description. If you do the latter, your future self will thank you!
As notes only save non-default values, it makes sense for the starting value to be false (the system default for all Boolean-type attributes). A good example from the Tinderbox system attributes is $HTMLDontExport. As most notes are expected to export when the TBX is exports (to HTML), peel away an implicit double negative for the false default, i.e. don’t don’t-export means ‘do export’. So a true value is only needed for those notes you explicitly wish to not export.
An alternative name for our user Boolean here, on reflection a bit clearer might be ‘BandNotActive’. If you have a term other than ‘active’ for a band/artist still performing (alive?) you might choose a different word.
In summary:
- Use attribute names that make sense to you, as long as valid in Tinderbox.
- In other than simple text TBXs, give your user attributes a description: what role do they perform?
- Name Booleans so their true/false nature is evident (‘has’, ‘is’, etc.).
- Align the naming style such that it describes the
true(i.e. non-default) state - what happens when the box is ticked in the UI.