PKM-er / obsidian-zotlit

A third-party project that aims to facilitate the integration between Obsidian.md and Zotero, by providing a set of community plugins for both Obsidian and Zotero.
https://zotlit.aidenlx.top
MIT License
651 stars 30 forks source link

[FR] Simplify templating and use a single template file #101

Closed FeralFlora closed 1 year ago

FeralFlora commented 1 year ago

Thanks for a very innovative plugin! I am trying to implement a nunjucks template in Eta for this plugin, but I'm finding it quite difficult.

One of the reasons is that only some aspects of templating are actually set in the template file, while others are implemented in the settings of the plugin or elsewhere. Here, I am thinking of the yaml metadata, for example.

Another example is the zt-annot.eta file. Here, I tried making it so that comments and annotations would be displayed as a bullet list like so:

<% if (it.imgEmbed) { %>
- <%= it.imgEmbed %>
<% } %>
<% if (it.comment) { %>
- <%= it.comment %>
    - <%= it.text %> p. <%= it.pageLabel %>
<% } else { %>
- <%= it.text %> p. <%= it.pageLabel %>
<% } %>

However, there are two issues. One, the zt-annots.eta template adds a newline between each annotation. Of course, I could change this, but I am just highlighting that having multiple files makes templating less predictable and transparent. Secondly, the list is not formatted correctly, because there are blockquote symbols > in front of every line, and I don't know where they are coming from. I cannot see these symbols in the zt-annot.eta template, so where are they coming from? See the image below:

image

Zotero Integration, which I am considering to move away from in favor of Obsidian-Zotero, went from three template files to one, and I think this plugin would benefit from going the same route. And also by not having parts of the template in the settings rather than the template file.

aidenlx commented 1 year ago

I am trying to implement a nunjucks template in Eta for this plugin, but I'm finding it quite difficult.

this plugin actually use the same templating engine as Templater plugin, you can find resources and examples in their community for now before I finish the document.

there are blockquote symbols > in front of every line, and I don't know where they are coming from.

since 1.0.0, the template for single annotation is warpped inside a callout so that imported annotations can be tracked correctly. if you want to unwarpped them, you can add frontmatter field callout: false in frontmatter of zt-annot template file.

Zotero Integration, which I am considering to move away from in favor of Obsidian-Zotero, went from three template files to one, and I think this plugin would benefit from going the same route. And also by not having parts of the template in the settings rather than the template file.

I am aware of this, the reason of choosing multiple template files is that the templates are re-used in different use cases, for example, zt-annot is reused when drag-n-drop annotation and rendering literature note.

I'll complete the document about using template properly before requesting plugin review in obsidian, stay tuned!

FeralFlora commented 1 year ago

since 1.0.0, the template for single annotation is warpped inside a callout so that imported annotations can be tracked correctly. if you want to unwarpped them, you can add frontmatter field callout: false in frontmatter of zt-annot template file.

Thanks for this piece of information. I think such behavior lacks transparency. Wouldn't it be possible to achieve the same behavior with the > symbols actually be present in the template file? Anyway, the yaml option works! However, I don't see any block-ids associated with the unwrapped annotations. Does this break some plugin behavior?

I did manage to implement most of my Nunjucks template in Eta for Obsidian-Zotero. I am going to share the follow templates in this thread I started on the Obsidian Forum for sharing Obsidian-Zotero templates.

Here's some sceenshots:

image image image

And the templates:

zt-note.eta:


# [<%= it.title %>](<%= it.backlink %>)

> [!NOTE]+ Info
> 
> [Open in Zotero](<%= it.backlink %>)
> [DOI](https://doi.org/<%= it.DOI %>)

> [!abstract]- Abstract
><%= it.abstractNote %>

## Notes
<%~  include("annots", it.annotations) %>

zt-annot.eta:

---
callout: false
---

<% if (it.imgEmbed) { %>
- <%= it.imgEmbed %>
<% } %>
<% if (it.comment) { %>
- <% if (it.comment.startsWith('todo ')) { %>[ ] **<%= it.comment.substring(5) %>:**<% } else { %>**<%= it.comment %>:**<% } %>  
    - ==<%= it.text %>== [p. <%= it.pageLabel %>](zotero://open-pdf/library/items/<%= it.parentItem %>?page=<%= it.pageLabel %>&annotation=<%= it.key %>)
<% } else if (it.text) { %>
- ==<%= it.text %>== [p. <%= it.pageLabel %>](zotero://open-pdf/library/items/<%= it.parentItem %>?page=<%= it.pageLabel %>&annotation=<%= it.key %>)
<% } %>

zt-annots.eta:

<% for (const color of ['#e56eee', '#5fb236', '#f19837', '#2ea8e5', '#ffd400', '#a28ae5', '#ff6666', '#aaaaaa']) { %>
<% let annotations = it.filter(annotation => annotation.color === color) %>
<% if (annotations.length > 0) { %>

<% if (color === '#e56eee') { %>
### ⚡ Hypotheses
<% } %>
<% if (color === '#5fb236') { %>
### 💡 Main ideas and conclusions
<% } %>
<% if (color === '#f19837') { %>
### ⚙️ Method
<% } %>
<% if (color === '#2ea8e5') { %>
### ❔ Questions
<% } %>
<% if (color === '#ffd400') { %>
### ⭐ Important
<% } %>
<% if (color === '#a28ae5') { %>
### 🧩 Definitions and concepts
<% } %>
<% if (color === '#ff6666') { %>
### ⛔ Weaknesses and caveats
<% } %>
<% if (color === '#aaaaaa') { %>
### 📣 Survey instruments
<% } %>

<% for (const annotation of annotations) { %>
<%~ include("annotation", annotation) %>
<% } %>
<% } %>
<% } %>
aidenlx commented 1 year ago

one hint, there is a helper field colorName that provide human-readable name for color label, and you can use Array.prototype.group available in template rendering to handle grouping of annotations

FeralFlora commented 1 year ago

@aidenlx Thanks, yeah, declaring the colors is not necessary. I will remove that part. I am unsure how to use this group() function. Could you provide an example?

aidenlx commented 1 year ago

you can check usage here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/group#using_group


<% 
const colorGroups = it.group(annot=>annot.colorName);
const colorLabel = {
blue: "⚡ Hypotheses",
...
};
for (const [color, annotations] of Object.entries(colorGroups)) {
%>
### <%= colorLabel[color] ?? 'Group' %>
<% for (const annotation of annotations) { %>
<%~ include("annotation", annotation) %>
<% } %>
<% } %>
FeralFlora commented 1 year ago

Thanks a lot, that example helped me simplify the template! I tried following the documentation in that link, but I kept getting errors.

I understand the reasoning for keeping multiple template files. In the end, I was still able to get the output I wanted. I think you can close this issue, but it would be great if you could answer these last questions:

since 1.0.0, the template for single annotation is warpped inside a callout so that imported annotations can be tracked correctly. if you want to unwarpped them, you can add frontmatter field callout: false in frontmatter of zt-annot template file.

Does this mean that unwrapping annotations from callouts breaks tracking? I don't see any block-ids associated with the unwrapped annotations.

And lastly, how come Zotero Integration has many more keys associated with items compared to Obsidian-Zotero? Is Obsidian-Zotero limiting the selection? I checked an item, and Zotero Integration's data explorer shows 48 keys, while the details view in Obsidian-Zotero only shows 31 keys. Missing keys include Collections, formattedAnnotations, hashTags, and attachment.path is incomplete and fileLink returns nothing. I know some of the Zotero Integration keys are redundant, but I think many are interested in keys like collections, attachment.path and so on.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open for 14 days with no activity.

github-actions[bot] commented 1 year ago

This issue was closed because it has been inactive for 14 days since being marked as stale.