Prototype and OnAdd Action

Seems the issue is fixed. But, playing along in the background, I’d add a tip.

Don’t get hung up on using a single view. Over time, especially when debugging container actions, I’ve found that outline view is the view in which to work.

If your reaction is “But I always use…” you are missing the point. All views are just different ways of seeing the same content. I think this is something beginners perhaps don’t grok.

As all views are available, when debugging, choose one that most easily gives you a tell back of what is going on in containers and children (heavy hint: it isn’t map view). But Map view sill works for your normal work, it’s just often sub-optimal as a view for debugging action code

2 Likes

Hi Michael,
here is another approach - you get a preferences note. There you define the prototypes for the childs in all your folders. You can have several folders for example of the type “article” and change the assigned prototype in the prefs note - no need to change an attribute in each folder.
I use an Edict and the $Name of the folder to find the corresponding preference.
I don’t know if this will be more flexible or add some speed - it’s just one small step for me to understand action code.
crossreference.tbx (103.1 KB)
Thanks for your inspiration!

Thanks. I’m not sure I understand the person of the Preference function. It seems to be an extra step. I must be missing something.

Also, in your $Edict you say:
if(!$IsPrototype){action("$AssignPrototype=$"+$Name+"(/pPreferences);")}

I don’t know what this is intended to accomplish. Also the action() wrapper in this context is unecessary. Action( ) is for export code, you don’t need it in action code.

Can you explain what you’re trying to accomplish with the above $Edict.

it’s just an experiment… for the OnAdd action $Prototype=$AssignPrototype(parent); I need the AssignPrototype attribute to be filled with the name of a prototype that will be assigned to all children of the folder.

The prototype for the folder comes with the filled OnAdd attribute and an empty AssignPrototype attribute. This because I would like to use the same prototype (“pFolder”) for different folder types (containing people, articles, ideas…).

The easiest way: enter the name of the prototype as string for each individual folder - “pPeople” for a folder containing notes with people and “pArticle” for the childs of a folder containing articles… this has to be done for each folder once. If you would like to change the prototype later you have to edit the attribute on each folder.

With my last experiment you don’t need to touch any of the folders at all. Just assign the prototype “pFolder” and this prototype will add the attributes and an Edict. The action code in the Edict just fills the attribute AssignPrototype. The value was taken from the note “pPreferences”. The values for all folders are there at a single place. If you need to change the assigned prototype of any folder → just edit the relevant attribute in the pPreferences note and all folders referring to this attribute will be updated at once (for example if you have more then one instance of a folder “Persons”).

To automatically assign a value of the pPreferences note to the individual attribute of each folder I take the name of that folder and look for an attribute with the same name in pPreferences. This is:

if(!$IsPrototype){action("$AssignPrototype=$"+$Name+"(/pPreferences);")}

I don’t want to execute the action code on the prototype - only on the notes that use the prototype. That’s the reason for if(!$IsPrototype){…}
Because the name of the attribute in pPreferences is different with each and every folder I need to define the name of the corresponding attribute dynamically. The only way is the action method: action("$AssignPrototype=$"+$Name+"(/pPreferences);")
For a folder named “Persons” this will give: $AssignPrototype=$Persons(/pPreferences); for a folder named “Articles” this will give: $AssignPrototype=$Articles(/pPreferences);

For sure there are better ways to solve this - as I wrote before: it’s just an experiment with different aspects of the action code. The practical use may be limited!

Gotcha, thanks for the detailed response. I’m going to have to study this.