For my work I nearly exclusively use IDs, I have a worldly that is extremely conducive to this.
Bunch of ways…e.g., display $ID, open the Quickstamp, pull it from action code.
Yes, in something like Displayed Attributes, but in a piece of code, such as a function, the source of $ID depends of the context in which is is run. It was the latter context, i.e. ‘code’, to which I was referring. By comparison, $ID in a rule will likely be for the note holding the rule, but not necessarily so withuot first parsing the code to check that assumption.
Displaying the path of a note when hovering over what might be an id is something that would have to be supported by the infrastructure of the TB code base. The feasibility would depend on the availability of a mechanism that maps an ID to its corresponding note. It is conceivable that this mechanism already exists. As for how to recognize a potential ID in action code, that is a parsing matter and should be easy. Note that none of this occurs in action space.
Actually, the hard part might be displaying a distinct hover above different parts of the code. It could be done, I think.
I’ve been spoiled by the UUID assigned to items in Devonthink — makes automation easier — find a document, grab the UUID, and I can move the document anywhere in the Devonthink database, but the UUID still identifies it.
Using paths seems contrary to automation for me because if I move a note, the path is gone. It seems as ephemeral as the id would be.
EDIT: I meant the applescript type of id, not the tinderbox $ID. Edited above to make it clear.
$ID is stable and unique within (but not between) documents.
1 Like
Nice! I hadn’t realized that!!!
Better still, $ID is very likely to be unique within all over your documents. But it’s not unique across all Tinderbox documents everywhere.
2 Likes
Ya, it is great. I use $ID for nearly everything.
1 Like
See, I am glad I asked. I had taken for granted that this was better than paths for me - that the $ID is unique for each note in each document works perfectly for me.
As long as I can do things like:
get every note whose name contains thisVariable
And then rip the $ID from each
Then I can move notes and things and not have to keep up with the paths.
I like it!
Yes, that works. Or you can do things like this:
$MyString="";
var:list vList=collect(children,$ID);
vList.each(x){
$MyString+=$Name(x)+"\n";
$MyString+=$Text(x)+"\n";
$MyString+=$Tag(x.replace(";",","))+"\n";
};
In the above example, you’re pulling the IDs for all the children. Then you iterate through the list of collected IDs and populate $MyString with the Name, Text, and Tags from each of the children, “x” being the $ID for each child in the list. Remember, “x” is just a variable, you can call it anything you’d like, e.g., 'iID, “anID”, anthing that makes sense to you.
Make sense? This is extremely powerful!!!
1 Like
Note that as of v950. we also have the option of $IDString.
I’d characterise a choice of $ID vs $Path/$Name as follows. $ID makes sense when you are using a lot of automation either in-app or in export templates as ^action()^ sections. A confusion arises between use of the attribute as a reference vs a literal value.
Values are more informative to see in code:
$Path == "/Path/To/NoteX:;
$Name == "NoteX";
than an ID:
$ID = 1023456789;
By comparison if using just an attribute reference, then $Path, $Name, $ID offer little difference:
$Path== $Path(original);
$Name == $Name($MyString);
$ID == $ID(vID);
The most important factor is that $ID, especially tucked away in code, will not trip up on characters in $Path or $Name that might confuse the action code parser (see Problematic Characters for Action code in $Name and $Path).
Generally, I’d suggest new starters should do fine using $Path or $Name for note references, until/unless they know they need to use $ID, e.g. due to pathname parsing issues. There is no one-size-fits-all guidance here.
1 Like
A rule of thumb:
$ID’s are shy. You should seldom or never see one, either in actions you edit or in $DisplayedAttributes.
Use $Name in small documents. Prefer $Path in big documents. When you must have several notes with the same name (especially if they are siblings and so have the same path) use $IDString.
I believe $IDString is always better than $ID, but $ID is slightly faster. I doubt the performance difference will matter in any but the most demanding jobs.
1 Like
Note, I find $ID extremely useful when iterating through a series of notes in action code to dynamically greater template output. I never actually “see” the IDs, Tinderbox does, what I get to see is perfectly formated HTML output. It is a beautiful thing.
$IDString would work just as well.
The main point is that people should not see $IDs, and should seldom see $IDStrings — and never should see either until they are of sufficient maturity!
Here are updated versions of the TBX to DEVONthink utility. Corrections (aka errors) involve handling of text links and embedded pictures. Also, in this version the INSTALLER is not active allowing för browsing material before install.
TBX to DEVONthink - Light.tbx (209.9 KB)
TBX to DEVONthink - Dark.tbx (193.5 KB)
4 Likes
Nice, I like it a lot!
Good! Hope it will be of use for you.
1 Like