It would be nice to obtain the highly functional UI for lookup fields we see in the default display when using custom display templates. A single line command designed to produce the HTML code for that purpose would be a great addition to the toolkit.
{:lookup:qauthors}
I expect the standard behaviour would be that the user always supplies the name of the lookup shortcut. In the example above the lookup shortcut is “qauthors”.
I’m just starting to link collections via lookups so my ideas here are a little bit green. It has just occurred to me that user defined templates would allow the user to determine how the lookup is rendered.
{:lookup:qauthors:lookup_qauthors.html}
Being able to generate the default lookup rendering template, in the same way that display.html and display.css are generated would be a great basis for custom lookup templates.
An optional second parameter in the command would provide the template path. I am imagining that these would operate in exactly the same way as includes.
The complication I can forsee is that there must be a way to identify which collection the field references belong to. I don’t know how much of an issue that is. Although from the user perspective, its obvious that we will want to mix fields together in all sorts of ways. I hope that there is some simple way to achieve this.
I think perhaps you already have access to the functionality you are looking for.
When you use a Lookup field, and the lookup field for a particular note is populated, and the “looked up” note can be found in the Lookup collection, then all of the fields in the “looked up” note become available to you, so long as those “looked up” fields have unique field labels, that are not already present in the primary note. No special syntax is required for the template variable.
As for the functionality found in the normal display, it can be easily replicated in a custom template, using code like the following:
<details>
<summary>
Author:
<a href="notenik://open?shortcut=authors&id=amandacross">
Amanda Cross
</a>
</summary>
<ul>
<li>
Author Info: American academic at Columbia University, a prolific feminist author of academic studies, and a mystery author.
</li>
<li>
Author Years: 1926-2003
</li>
<li>
Author Link:
<a href="https://en.wikipedia.org/wiki/Carolyn_Gold_Heilbrun">
https://en.wikipedia.org/wiki/Carolyn_Gold_Heilbrun
</a>
</li>
</ul>
</details>
Well, you would typically want to plan your fields so that they don’t conflict. If they do, and you want to use them in this way, then you would need to rename one.
Across three files I have these field name conflicts.
Date Added: <dateadded>
Date Modified: <datemodified>
Link: <link>
Tags: <tags>
Body:
I assume that I can rename most of these fields with collection specific labels without interrupting their functionality. For example, in the Contacts collection they could become:
Date Contact Added: <dateadded>
Date Contact Modified: <datemodified>
Contact Website: <link>
Contact Tags: <tags>
What do I do about the Body? I’m guessing that I can’t bring that across because I can’t rename it.
Oh, sorry to create noise. I see that I can rename it, provided I specify the field type is .
Unfortunately my first attempt has created mayhem. In edit mode I was seeing duplicates of Title, Tags, and Body. After I changed the field labels in the template, the existing notes were out of synch.
Providing the correct label names rectified everything.
I can see how beneficial that would be. In my early fumbling I made changes to templates that produced very confusing results. A wizard to assist this process would have helped me avoid that confusion. [^1]
I’m thinking that info.nnk would carry a serialised map of the template that you could compare with template when it is loaded. In simple cases, such as adding a new field, notenik can manage without needing to nag the user. But there are a lot of issues to handle that are out of reach of an algorithm. I changed the name of fields, at the same time I added new fields, and I changed the order of the fields. An algorithm would struggle with that, and getting it wrong is worse than not doing it.
A wizard similar to the one you provide for the Query report might be the way to go. In the first place, it could be offered to users as an alternative to direct editing of the template. That allows the user to do the field mapping themselves. If the user does edit the template directly and info.nkk senses changes that cannot be reconciled automatically, it could then display this wizard as a way of asking the user to clarify their intentions.
Field
Type
Seq
New Label
+ add new field
Title
title
1
Full Name
Tags
tags
2
Contact Tags
Link
link
3
Website
Date
date
4
Birthday
Body
body
5
Notes
[1]: I think that notenik does not frighten users who are familiar with handling text, especially text as data. Its appeal would broaden if users had an option to manage these defining tasks within the app.