When should you think about using $IDString over $ID?

Q & A - getting started with Tinderbox
1

I am not clear when one should think about using $IDString over $ID. I think I understand that if you have files with similar names, you should think about using $ID over $Path (i think) but I am not clear between $ID and $IDString. Not sure if anyone else has this question, but this is definitely a gap in my understanding.

Thoughts or ideas welcomed.
Tom

2

Very broad view: most people never need to know that $ID and $IDString exist. Use $Path to designate notes.

Broad view: The $Path of a note is based on the note’s name, and the names of the notes that contain it. For example: /Shakespeare/King Lear is the note “King Lear” inside the container “Shakespeare”.

This can run into trouble if the container Shakespeare holds two notes, both named “King Lear”. The $Path of each of these notes is identical. The best solution is usually to give the notes unique names, for example King Lear (quarto 1608).

Sometimes, that’s impractical or undesirable. In that case, you can use $IDString instead; the $IDString of each note is unique. (You could use $ID, too, but $IDs are hard to remember and type. So prefer $IDString)

Also, a few characters cause trouble in $Path. For example, suppose you have a note named S/Z: an essay.. Its $Path will be something like Criticism/Barthes/S/Z: an essay. But that looks like there’s a note “Z: an essay” inside the container S. (“Z” was a fine movie, but it’s not literary criticism).

Again, the best advice is, “just don’t do it!” Avoid / in names, Avoiding [, {, and \ is also prudent. (This is only a factor if you expect to use $Path, which lots of people won’t need.)

But is may be infeasible to avoid these characters in note names, and you might need to use $Path. If you do, using $IDString.

1 Like
3

Crystal clear. Thank you Mark.
Tom

4

Rounding this out, the issue of not using $Path, and of and problematic paths, tend to only rear its head is you use action codes related to linking (i.e. not all action code).

NOTE: if you don’t do action-based linking or link-derived querying, this niche subject can be ignored.

Given the advice up-thread, I’ve now updated my page on ‘problematic’ characters, adding the square and curly brackets to list of characters of which to beware. Remember, this only affects a small number of users doing quite specific tasks.

1 Like
5

As the original question, i.e. why $IDString not $ID (as opposed to not using $Name it $Path), it is again a niche issue.

$ID is a Number-type attribute and the values are all 10-digit numbers. If a user is using $ID in action code, in some edge-cases, the ID number can get treated as a number and then subjected unintentionally to arithmetical operators. $IDString, as an explicit String, holds the same unique note IE, but encoded in a string.

In truth, if you are one of the small grip of user actively employing $ID and you don’t have the above edge case problem, you do not need to update all your code using $ID.

Note: The hash function making the ID strings supplements the range A-Za-z0-9 with a few other characters notably forward slash / and plus-sign +. So be careful using literal $IDString values in paths and URLs. Edge cases beget edge cases.

1 Like
6

Note, it is for this very reason that I use $ID rather than $ID string. I use $ID to populate the $HTMLExportFileName attribute with a notes $ID, that way I have no note name collisions during preview or export.

7

I think Mark is recommending using $IDString instead of $ID. In addition, MarkA added that $ID uses a number rather than a string data type.

I see more advantages to using $IDString over $ID. What am I missing?

From your perspective, MichaelB, why do you continue to use $ID or $IDString?

Tom

8

$ID has been available for a decade, but $IDstring has only been available for a few months.

9

Yes, he is in general, however, $IDString with the “:” and various elements does not resolve well as an HTML path name for export.

10

good point… thanks
Tom

1 Like