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:
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.
Display a popup for taking input from the user for the user-definable variables.
Run the script based on the script path giving the user defined variables as input.
Set variables from inside the script (can also be different to the user defined variables!)
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.
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.
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.
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.
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.
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.
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).
