Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com)
Tinderbox Users >> Questions and Answers >> Alias and Sandbox attributes

Message started by Tony Vilhelmsson on May 4th, 2016, 3:18am

Title: Alias and Sandbox attributes
Post by Tony Vilhelmsson on May 4th, 2016, 3:18am

I want to have a List on the original Note that keeps tracks of the paths of Aliases. To be able to keep the List up to date I have  a need to store the Notes old path so when moved I can on the Add remove the old path and add the new one.

Alternatively I guess one could o one of following:
1. Usa an Agent to find all notes that are Aliases and where Original is the Note in question.
2. Create a link type and Link Aliases and then use the link type to find all aliases and paths...

Which way to look?

Title: Re: Alias and Sandbox attributes
Post by Mark Anderson on May 4th, 2016, 3:47am

Agents are designed to resolve to a single match per note-and-all-its-aliases, preferring the original as a match if present amongst the matches. So, if a note has 4 aliases you can't construct an agent that will find all 5 items. Anyway, an alias inside a note is also an alias so the process is potentially never ending! Tinderbox doesn't treat the aliases formed dynamically by agents as different from those generated manually by the user.

However, find() will return a list of all notes matching a query, including all discrete aliases without de-duping. You can't use find in an agent but a rule, or far better - an edict, can handle this. An edict is good as it runs on creation and then about once an hour when the doc is open; it can be run once on-demand by using File menu -> Update Agents Now. An edict is is more efficient than a rule which is running all the time, especially if every note is constantly polling the whole document for potential aliases.

For a note needing to track its aliases, set the note's edict to:

$MyList = find($Name==$Name(that) & $IsAlias==false);

Tested in v6.5.0.

Might I ask for what purpose you're wanting to track aliases?

Title: Re: Alias and Sandbox attributes
Post by Tony Vilhelmsson on May 6th, 2016, 4:49am

Well, Things consists of Parts that could be in Pieces. One could model this is Note(protoThing) contains Pasrts(protoPart) that then contains Pieces(protoPiece). The idea was to create all of these items as notes and use Thing and Part as containers.
Then I could create other "objects" like House, Room etc that describes things but also location. Then use these notes to add the aliases of the things (or their parts/pieces).
Then if I could keep track of the Paths of the Aliases on the Thing I could see all places to visit to collect them.
Then again adding more dimension like time it starts to get a bit messy.
However just after your reply I found another odd thing (in my world that is) and thats that an Alias does not keep the originals Contant. So if the Original contains other notes those are to visible in the Alias either. I was expecting that opening an Alias would work more as opening the Original and that the view would be linked back to the Original view.
Since it's not I think I'll have to rethink the whole idea a bit.

Title: Re: Alias and Sandbox attributes
Post by Mark Anderson on May 6th, 2016, 8:51am

You are correct, aliases do not contain content. The descendants of the original can be queried (and exported - I think). Aliases share their original's $Text and outbound text and web links. The original's attributes are shared by the alias (i.e. when displayed/queried) except when the attribute is intrinsic. the latter occurs so as to allow an alias to do things like have a different map position or size compared to its original.

Aliases and links: see here. Note that $InboundLinkCount and $OutboundLinkCount aren't intrinsic. If you want to use discrete alias-based basic links you'll need to use Roadmap for the alias to find the true in/out counts and to interrogate its links. Browse Links also uses the alias' outbound basic link data *if* that differs from the original. In other words, opening either of these dialogs may offer different data if the original or an alias is selected. As the link count attributes aren't intrinsic, alias basic link counts can't be checked via action code.

This may seem byzantine at first sight. However, these nuances exist for a purpose as different sub-groups of users use aliases in very different ways. Some of these conflict and the result is a best attempt to support as much use as possible.

If you need fine detail on alias linkage for a specific project/workflow I'd suggest contacting Eastgate directly as there be additional alias nuances as yet undocumented by users.

Meanwhile, I do wonder if prototypes 'bequeathing' children might help with what you're trying to do - with or without aliases: see here. Regardless aliases cannot act as a container, and I suspect that is one aspect unlikely to change (due to the complexity it introduces back-of-house for the app).

Tinderbox User-to-User Forum (for formal tech support please email: info@eastgate.com) » Powered by YaBB 2.2.1!
YaBB © 2000-2008. All Rights Reserved.