The only difference between a rule, an edict and a stamp is periodicity and scope. A rule runs constantly on its ‘host’ note. An edict does the same, nut deliberately less frequently as in big/heavily coded docs rules may become a bottleneck†. Essentially an edict aims to run on start-up and then c.1 and hour, although it can be triggered on demands: see more.
A stamp differs in scope and timing. A stamp is an action that can be run on selection of one or more note(s). A stamp is always run on demand and execute once on each selected note.
So by moving code from a stamp to an edict you are:
- restricting it to running on the note holding the edict
- running whenever the edict is triggered.
Of course, if the edict is set in a prototype, then all notes using the prototype inherit the same edict by default. The prototype approach makes it easy to correct 00s of notes simply by editing the rule or edict in the prototype.
A find() is a query—as you’d use in an agent. In queries a reference, e.g. $Name, refers to the note being tested, i.e. every note—in turn—in the scope of the query.
If you want to test for an attribute value in the calling note, e.g. here the note running the edict, you can use the designator ‘that’ (see more). Thus your edict code:
var:string name = $Name;
find($Tags.contains(name)).each(path) {
linkToOriginal(path, name + " tag");
}
can alternatively be written—to the same outcome— as:
find($Tags.contains($Name(that))).each(path) {
linkToOriginal(path, name + " tag");
}
If a note is called ‘ant’, the above code will find and link to any (original) note where that tested note includes a $Tags value ‘ant’. Thus, in my test below, a note called ‘ant’ links to the originals of two notes that contain a discrete $Tags value of ‘ant’:
Looking at the note running the edict we see it has 2 outbound links of linktype “ant tag”:
Here is the test document: find-tag1.tbx (121.1 KB)
What were you expecting to happen?
As regards specifying offset references for attributes, i.e. getting/setting an attribute is a different note from the current one, see more here.
Action code has evolved greatly over the life of the apps with syntax gaining in capability over time. I believe it borrows from conventions of a number of sources (but not formally recorded as such). A useful way to compare this is by looking at older versions of aTbRef, all of which are still online.
Action code is best understood in terms of the available Tinderbox documentation (app Help, app Help menu tutorials, and aTbRef), rather than trying to derive syntax from some other language. In parts it may look like [some language] but that doesn’t necessaerily apply across all code.
[Disclaimer re aTbRef: I am aTbRef’s (sole) author]
†. Most users will never meet this. It generally relates to ‘power users’ doing complex tasks or a small subset of new users who just apply rules to everything and then wonder why the app is working hard.
