Specifying note title and tags in templates

uxamanda · 2021-08-11T16:35:13.071Z

These seems like a good proposal to me. This also allows for later reserved variables for things like a due date or other metadata type things. Makes me wonder if there should be a better rule for name spacing, i.e. template_ so template_title, template_tags and let users know that at any time a template_ variable may become reserved so they shouldn't use them (even if you don't actively prevent it).

Other thoughts:

Would it be possible to keep the handlebars style tagging for those? I feel like switching tag styles is confusing. I realize that may be a huge technical hurdle though, so probably ok for a v1
FYI, I immediately feel like people will want / try to use these special variables in their note, so if that can be accommodated, it will probably be good. (for example, someone wants the note title at the top of the page, or to visually see the list of links)

laurent · 2021-08-11T16:47:59.893Z

Indeed I missed that it was a recent proposal. Wouldn't it be possible to use the template note title as the new note title?

nishantwrp · 2021-08-11T16:51:09.010Z

nishantwrp:

Their values can be used as normal variables in the template body.

Is this what you mean by your second point?

uxamanda:

Makes me wonder if there should be a better rule for name spacing, i.e. template_ so template_title , template_tags and let users know that at any time a template_ variable may become reserved so they shouldn't use them (even if you don't actively prevent it).

Good point, makes sense. We can use template_.

uxamanda:

Would it be possible to keep the handlebars style tagging for those? I feel like switching tag styles is confusing. I realize that may be a huge technical hurdle though, so probably ok for a v1

Actually the brackets {{ }} have a significance in yaml too, and are not treated as a string by our YAML parser. So, to use the same brackets, I'll need to implement a customer yaml parser and that seems too much for this feature. Probably, we can go for <% %> for v1 as you said.

nishantwrp · 2021-08-11T16:52:15.586Z

laurent:

Wouldn't it be possible to use the template note title as the new note title?

We can do it, but now with this feature the user can cutsomize the title. So, I think that this is better than using the same title.

laurent · 2021-08-11T16:54:38.132Z

nishantwrp:

We can do it, but now with this feature the user can cutsomize the title.

I might be missing something but why can't they customise the title if it's the actual template title?

nishantwrp · 2021-08-11T17:00:07.349Z

laurent:

I might be missing something but why can't they customise the title if it's the actual template title?

For example, They want to have the minutes for a meeting. They currently have two projects, Proejct 1 and Project 2. With this feature, they'll be able to use variables in the title and it could be dynamic.

For example,

---
project: enum(Project 1, Project 2)
note_title: Meeting Minutes - <% project %> - <% date %>

---

## Meeting Minutes
*Write notes here*

Now, when we create a new note with this template and select Project 2 say in the selector. The title would automatically become Meeting Minutes - Project 2 - 11/08/2021.

laurent · 2021-08-11T17:17:00.318Z

Thank for clarifying. But what if the template title is Meeting Minutes - <% project %> - <% date %>? I guess the title is not currently being processed by Handlebar but maybe it could?

nishantwrp · 2021-08-11T17:21:52.147Z

Ah, that's a nice idea! But we want to do a similar thing for tags too. How do you think we do that without creating a variable?

IMO, creating tags with titles like <% project %> would be a bit weird. What do you think?

Btw, I like this approach you suggested. In this way we'll be able to avoid using <% %> brackets and use the same handlebars style brackets i.e. {{ }}.

JackGruber · 2021-08-11T17:29:48.044Z

Is the problem with { } a error like All collection items must start at the same column?

nishantwrp · 2021-08-11T17:33:05.201Z

In the YAML parser? It actually, assumes the value as null. For. eg.

name: text
note_title: {{ name }}

The parser reads the value something like

{
  "name": "text",
  "note_title": null
}

JackGruber · 2021-08-11T17:37:29.487Z

Yes in the YAML.

I think you need to write it like:

name: text
note_title: "{{ name }}"

or

name: text
note_title: Project {{ name }} meeting

because when the value of the option starts with an { and ends with an } I mean they think this is an Object on parsing and make the following:

{
  "name": "text",
  "note_title" {
      "name": null
  }
}

nishantwrp · 2021-08-11T17:43:41.450Z

Oh, ok. Didn't know that. Thanks for this. I'll try and see if this works.

UPDATE - It works! We can use the same {{ }} brackets.

nishantwrp · 2021-08-11T19:02:46.327Z

According to me there are two points that need to be discussed before implementing this feature.

Using template_title and template_tags instead of note_title and note_tags and informing users that they should avoid using template_ variable names as they may become special variables in the future.
Should we use the actual template tags and title instead of special variables?

JackGruber · 2021-08-11T19:08:32.942Z

nishantwrp:

Using template_title and template_tags

I think the naming template_ for special variables of the plugin is a good choice.

nishantwrp:

Should we use the actual template tags and title instead of special variables?

Not for tags, because they can no longer be made dynamic.
For the title possible, but could look a bit confused in the overview, but to make it consistent I would also put it in the YAML area and at most if none is defined use the title of the template.

tessus · 2021-08-11T19:16:54.026Z

Will something like this work now?

note_title: Sprint {{bowm}}

nishantwrp · 2021-08-11T19:21:14.399Z

By now, do you mean when this feature is implemented? If yes, then yes.

codyburleson · 2021-08-13T14:31:26.175Z

Maybe I don't fully understand, but this seems a little overengineered to me. Why not just allow variables in titles and be done with it? By simply allowing template variables (one to many) in titles, you effectively accomplish the same thing without the need for special reserved variables.

nishantwrp · 2021-08-13T14:58:40.351Z

Actually, we have to do the same tags and maybe in the future for target notebooks (you can read this). If we want to do it for title only then using the template note title seems good.

uxamanda · 2021-08-13T17:14:28.863Z

JackGruber:

For the title possible, but could look a bit confused in the overview, but to make it consistent I would also put it in the YAML area and at most if none is defined use the title of the template.

I like this as a solve - if the user doesn't have a template_title or template_tags in their yaml, it uses the one from the template itself, otherwise the yaml overrides. Although I am guessing the "template" tag itself would not be inherited

JackGruber · 2021-08-14T13:56:54.999Z

codyburleson:

Why not just allow variables in titles and be done with it?

I don't like it when all the variables appear in the template selection.
In addition, I would find it great if the templates are called differently than the created note then, especially for the dropdown selection are speaking names more meaningful.

Project meeting
Project ToDo
...

and not

Standup {{bowm}}
Meeting {{project}} on {{date}}
{{project}} - {{taskdescription}}

Maybe you should consider to put the note options and the variables in their own section, so that there are no name overlaps?

variables:
  name: text
  project: enum(Project 1, Project 2)
  notebook: text
  tags: text
  test:
    label: Text for the input mask
    type: text
    ...
note:
  tags: daily, {{tags}}
  title: Meeting project {{project}} on {{date}}
  notebook: {{project}}
  ...