This version is out of date, covering development as far as v4.2.5. It is maintained here only for inbound reference links from elsewhere. Jump to the current version of aTbRef. |
A Tinderbox Reference File : Attributes : System Attribute List : Container |
Container |
Attribute Data Type: | string |
Attribute Default Value: | (path to the note) |
Atrribute Group: | General |
Attribute Inherited from Preferences? | No |
Attribute Read-Only? | No |
New to v4.1.0, the Container attribute lets Tinderbox actions and rules change the parent of a note, moving it to a a new place within the document.
A key usage to to enable automatic sorting of notes created via emails sent to Tinderbox.
The default value of Container is the Tinderbox path to the note, with ancestor note names delimited with a '/' (forward slash). Thus this note's Container value is:
^get(Container)^
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 from v4.0.0+).
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 don't currently exist will be created. 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 can't 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).
Although Tinderbox doesn't allow this and other such methods to delete 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.
Also from v4.1.0 email to Tinderbox allows the same Container-setting action to be specified within an email.
Up: System Attribute List | |
Previous: Color2 | Next: Created |
Licensed under Creative Commons Attribution-Noncommercial-Share Alike 3.0 License
[See aTbRef CC licence Attribution/Waiver info info]