Attribute Data Type:
Attribute Default Value:
Attribute Group:
Attribute Purpose:
Attribute Inherited from Preferences?
Attribute UI-configurable?
Attribute Read-Only?
Attribute Intrinsic?
Attribute First Added:
Attribute Altered:
string [other string-type attributes]
(preset to parent's path)
General [other General Group attributes]
General data
No
No
No
Yes
Baseline
Lets Tinderbox actions and rules change the parent of a note, moving it to a a new place within the document.
It is the parent's $Path plus a '/'. For any item, $Path is the equivalent of $Container + $Name. More on moving notes.
The underlying default value of $Container an empty string, but this is never seen as at note creation Tinderbox always inserts the path to the note's parent, with ancestor note names delimited with a '/' (forward slash) and the $Container of any root-level note is "/".
Originally, a key use is to enable automatic onward routing of notes created via emails sent to Tinderbox (a feature currently suspended).
A more useful example would be for children of a document's 'Mail' note, used for collecting inbound email. Using monthly archives might result in a structure like '/Mail/Dec 07/', i.e. a note 'Dec 07' found inside the note 'Mail'. An action in Mail might be to set the added note's container to 'Dec 07'. Thus:
$Container="/Mail/Dec 07";
…will move the inbound email note from 'Mail' to 'Dec 07' inside 'Mail'.
Note that the value passed in the action is a quoted string (now the recommended method for string literals).
An alternative to a quoted string is an attribute value:
$Container = $MyPathAttr
A neat feature of this process is that any notes/containers in the path that do not currently exist will be created. Note: the latter is a exception to the general rule that Tinderbox will not automatically create or delete notes. Thus for more advanced users, the 'Dec 07' note name could be a value computed from the current date allowing the document to add a new folder each month without the user having to bother with this task.
If the destination container has an $OnAdd action, that action is is performed immediately on the newly added note(s). Note that if the action tries to move a note into the container in which it currently resides the $OnAdd action is not run; this makes sense as such an action will have already been run when the note was first added.
If a note cannot be moved, either because it is being moved inside its own descendant or because the destination is not a (valid) container (e.g. an adornment of some other special note type), no action occurs.
If using an agent to set a new container, it is important to consider whether the aim is to move the original of the note or merely the note's alias within the agent. Thus an $AgentAction like:
$Container(original)="Some Note"
…moves the original of the note matched by the agent to a new location. Conversely:
$Container="Some Note"
…moves the currently-processed agent alias.
Important: moving the agent's alias will cause the agent's current cycle to cease, so ensure that the processed note no longer meets the agent query or only the first matched item will move its alias. Otherwise, the agent action will move one alias per cycle.
Although Tinderbox does not allow code-deletion notes, you might consider setting a 'Trash' note and using a $Container="/Trash"; action. The Trash container could then be reviewed for manual deletions, or retrieval of erroneously trashed notes.
One other important consideration when using $Container is inheritance and the effect of moving on existing inherited values. If using a lot of prototypes/inheritance it is certainly worth taking extra care with use of $Container.
Email to Tinderbox allows the same $Container-setting action to be specified within an email.