Template Plugin

Another option which might be easier to implement but which is also less user friendly would be to give a path to a script as a variable. Your suggested pipeline would then look something like this:

  1. We first scan the text using regex and find all user-definable variables and a script path, their types. And remove the declarations from the text.
  2. Display a popup for taking input from the user for the user-definable variables.
  3. Run the script based on the script path giving the user defined variables as input.
  4. Set variables from inside the script (can also be different to the user defined variables!)
  5. Render the final text.

This would mean that there would be two different types of variables inside the template, some that will be input by the user and some that will be computed by some script.

Example:

---
user_variable1: string
user_variable2: string
script_path: script('/path/to/simple_addition_script.js')
---

Since you gave me variable 1: {{user_variable1}} and variable 2: {{user_variable2}} I conclude that the sum of both is {{script_variable1}}

In this case user_variable1 and user_variable2 will force a popup to the user while script_variable1 will be set by the script (That is loaded at some point and takes user_variable1 and user_variable2 as input, computes the sum of both and returns a dictionary with all variables to set, in this case script_variable1).

Handlebars supports custom functions so maybe we can support this without much trouble? Although if it gets too complicated it's probably best to keep that as a possible stretch goal.

2 Likes

In past discussions there was a lot of pushback from users about having a dedicated notebook for templates. Do you have any thoughts around declaring template notes instead of templates? Or perhaps another solution?

No rush, but could you create a mockup of how you expect this too look?

I absolutely love this idea! Dealing with raw markdown files in a hidden file system folder is weird. Making templates a notebook is brilliant!

I'm a programmer but my wife is not, and she's switching to Joplin and enjoying that! That's something that doesn't happen very often with my other open source choices and is a good indicator about the app quality. I'm sharing this because yes, you can have scripts, handlebars and all that stuff, but don't forget about normal users basic use cases. Just providing a simple, integrated, straightforward way to manage templates would be a huge win.

I think most users will just put some text to replace and will never write a real place holder (although I'm not saying they aren't important).

Now just a couple of aspects to please keep in mind.

First, please make sure that, if any templates are shipped by default, they are translated. English-only defaults look like junk for non-native speakers. When I showed her Joplin for the first time, she liked it and said: "So, it's like Notion but in Spanish", and that was a deal breaker.

Also it would be nice if there were some way to easily share and download templates. In notion, for example, you can google for recipes templates, land in Notion – The all-in-one workspace for your notes, tasks, wikis, and databases. and, with one click, use it. When she tried the same for Joplin, she ended up into some random github repo with markdown files. Maybe supporting some joplin:// protocol would help? At least, opening a markdown file in Joplin should allow to save as template.

I think it’s better to complete the first available version, release the actual test and accept feedback before deciding what to do. . . The above thoughts are really too complicated. The 2/8 law clearly states that most advanced functions are not commonly used by 80% of users. Therefore, it is recommended to implement a basic version first, and then decide whether to extend it to more. Complex model

Many extended functions are pseudo-requirements, especially scripts. In JetBrains IDE, custom scripts are not even supported, but only some form of placeholders are supported. But supporting placeholders will cause many problems, including more complex template editors, editor cursor jumps, and so on.

2 Likes

Sorry, I didn’t get you.

Also, for the popup I’m willing to use joplin views dialog api and some basic css.

Some users will not be willing to have a dedicated notebook that is only used for templates. They might want to store templates spread throughout different notebooks. Or they might not want want templates and notes mixed at all (this is based off previous discussions we've had on this forum).

It would be great if you could find a good compromise that works for as many users as possible. The final decision might be to just use notebooks as you proposed, but you should get more feedback from the community before deciding.

Of course, but a mockup is useful before you get to the coding stage.

Got it. Thanks for clarifying. Hmm, at the moment I can't think of anything that would a good compromise except implementing all of these options and give the user an option to choose from. But things still go messy if user wants to later change the option. Anyways, I'll create a separate topic to take an opinion from the community on the issue.

2 Likes

A special tag reserved for templates?

1 Like

I did think of this. But the main problem is comprising b/w people who like the notebook idea and ones who don't prefer templates in their notebooks or as a note at all.

PS: Created a topic for this Opinion on the templates should be organized - #2 by nishantwrp

I suppose only the last option is problematic, the first 2 can easily be handled with a tag.

EDIT

Maybe you should create a poll? It's easier for users to just click a button rather than type a whole message so hopefully you'll get more responses this way.

How do I do that within discourse or should i post an link to external poll?

1 Like

Thanks, created a poll. Opinion on the templates should be organized - #3 by nishantwrp

Please take a look at Deprecating pre-installed template feature

Important Links

1 Like

Updated Plan

Week 1

  • Initialize Plugin Framework
  • Setup Github Actions
    • Lint Checks
    • Build Checks
    • TypeScript Check (If not covered by above checks)
    • Unit Tests if needed further
  • Implement Notebook System
  • Created a command to expose joplin prompt to plugins

Week 2

  • Create the basic newNote, newTodo, insertText options.

Week 3

  • Work on default templates functionality.

Week 4

  • Complete default templates functionality.
  • Introduce handlebars and make sure all the current templates are compitable with the plugin.

Week 5

  • Create UI for variable input component.

Week 6

  • Write parsers for variable syntax.

Week 7

  • Complete variable feature.

Week 8, 9, 10

  • Finalize the way to handle the transition of users to this plugin.
  • Update documentation.
  • Finalize and implement the way to store the templates. (Tags, notebook, etc.)
  • Removal of original feature from the main codebase.
  • Release the final version of the plugin.
1 Like

Thanks for the updated plan, but note that removing the feature from the codebase may take a bit more time than you think as there will be a review process.

It's also key to your project because if the feature is still there by the time you finish, there's no need for the plugin at all. So what I would suggest is to create a pull request to remove the feature as soon as you can. That will get things started, then the reviewing process can happen in parallel to your other tasks.

1 Like

Yup sure, I'll try to create the PR next week. Just to be clear, The PR will be merged only after the plugin is complete, right?

Once it's ready it will be merged, but it will be in a separate branch so that we can test without having to make it part of an official release (or pre-release).

1 Like