Welcome, Guest. Please Login
Tinderbox
  News:
IMPORTANT MESSAGE! This forum has now been replaced by a new forum at http://forum.eastgate.com and no further posting or member registration is allowed. The forum is still accessible via read-only access for reference purposes. If you wish to discuss content here, please use the new forum. N.B. - posting in the new forum requires a fresh registration in the new forum (sorry - member data can't be ported).
  HomeHelpSearchLogin  
 
Pages: 1
Send Topic Print
Alias and Sandbox attributes (Read 791 times)
Tony Vilhelmsson
Full Member
*
Offline



Posts: 2

Alias and Sandbox attributes
May 04th, 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?
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Alias and Sandbox attributes
Reply #1 - 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?
Back to top
 
« Last Edit: May 4th, 2016, 3:47am by Mark Anderson »  

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Tony Vilhelmsson
Full Member
*
Offline



Posts: 2

Re: Alias and Sandbox attributes
Reply #2 - 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.
Back to top
 
 
  IP Logged
Mark Anderson
YaBB Administrator
*
Offline

User - not staff!

Posts: 5689
Southsea, UK
Re: Alias and Sandbox attributes
Reply #3 - 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).
Back to top
 
 

--
Mark Anderson
TB user and Wiki Gardener
aTbRef v6
(TB consulting - email me)
WWW shoantel   IP Logged
Pages: 1
Send Topic Print