I’m here again to ask for your help. I’ve been using your fantastic Modal Form Plugin for a few months now, and it has solved many problems for me. I can’t thank you enough for that.
Now I have a question:
I would like to use tables to enter multiple data points. Let me explain: I open my form and, under the “item code” field, which is a dataview type field, I show all the item codes contained within a directory that includes all the notes for the item codes. Each note reports, besides the item code, also the weight and the selling price.
So, from the form, by choosing an item code, I would like the other two values (weight and selling price) to be automatically assigned to the respective properties of the new note we are about to create.
Do you think it is possible to implement this functionality?
Were you ever able @Cyberpunk to resolve this? I have the exact same setup, where I currently use this approach in a Templater template that I’m trying to convert to a Modal Form.
In my tests, I’m unable to populate the values for the list. I also see no difference in having a Static list with or without any predefined options in the form definition.
I think all is needed to do what you want is to have the dataview source have access to the current form data, that way you can decide what to query and what to display. Will that work?
The values provided to modal-form for a list are not for the options to choose from, are a default set of already chosen values for multi-select lists.
The only way to populate the list options is either providing them as a fixed list when creating the form, or using dataview as source and build the list inside the dataview code snippet.
Does that make sense? If not, please give me the details of what you are trying to accomplish and I will try to give you an example of how that can be done
This release introduces the concept of hidden fields.
The intended usage of this feature is to provide values to the form that are not visible to the user.
This has some applications such as:
providing variables to the form-runtime that your dataview functions can use
having certain fields deactivated using the conditional without any user interaction
having certain values be part of the generated result, and used in the templates
I bet the community will be able to figure out some other interesting use-cases.
The reason I like this approach to much is a) because it is a web standard (this is common practice to communicate between backend and frontend in forms) and b) it plays nicely with all the existing form mechanisms without having to complicate the logic at all: formatting the output, reading the value from dataview functions, conditional rendering other fields, etc.
This release introduces a new input, the “markdown block”.
Just like the existing “document block” this is not a real input, but more a building block for richer forms.
The definition is expected to contain a function body returning a markdown string. This markdown string will then be rendered
into the form and the user filling it will be able to see it.
To illustrate with an example, imagine a simple form with a single text input, we can define a markdown block with this content:
return `# hello
- line 1
- ${form.text}
- ![[image.png]]`
Have you noticed the image syntax? Yes, images are supported too.
This is how it looks once rendered:
Both Markdown block and document block now have access to the dataview API (along with the form data itself).
This allows to build much complex and data packed information panels.
To access the dataview API, you do normally just like in any other place using a special variable named dv.
For example, and continuing with the markdown example, we could render a list of all the people (in markdown) using dataview
like this: