[Feature request] Variables in Forms

[zanodor]

Is your feature request related to a problem? Please describe.

Specifically dates. I find it too fiddly to set today's date and there is no way to do plus THH:mm.

Describe the solution you'd like

Some in-form method I cannot describe.

Additional context

Additionally, if I have:

  tR += "---" + "\n"
  const modalForm = app.plugins.plugins.modalforms.api;
  const result = await modalForm.openForm("default_notes_form");
  tR += result.asFrontmatterString();
  tR += "dateCreated: " + tp.date.now("YYYY-MM-DDTHH:mm");
  tR += "\n" + "dateModified: " + tp.date.now("YYYY-MM-DDTHH:mm");
  tR += "\n" + "---" + "\n"

...would there be a different way, I wonder?

This works, so don't wreck your brain or spend too much time over an alternative, of course.

Awesome plugin, I would love to see you be rewarded by Obs. Team in some way.

Cheers,

Z.

[danielo515]

At first I thought you were just asking about providing default values, but now I see what you mean, and I see why it is convenient. Maybe I can accept an option of extra-values, that will be incorporated in the result, giving preference to the result, or add a new field option to mark a field as hidden, so you can "inject" those values when calling the form. I'm open to suggestions of what you will consider more comfortable to use. For example:

  const result = await modalForm.openForm("default_notes_form",{extraValues: {a: 55}} );

However, that requires an entire new section of the result to parse and handle it properly, while adding the option to hide a field will re-use all the existing machinery

[zanodor]

My idea was about reducing the Templater lines and asking Modal Forms to do more. But I agree you don't want to write a new Templater inside Modal Forms.
I just feel users currently are shying away from using the plugin because they don't know how much Modal Forms can do and cannot do. So users don't know the scope of the plugin and what to inject over what little they know to inject through Templater itself. It's like a woman and man dancing: the woman expects the man to lead but he cannot dance so the man (the average Obsidian user) sits on his chair not dancing.

Also, what I meant above is the need to add --- fences... if Modal Forms use processFrontmatter behind the scenes, will it not create the YAML fences if they don't exist (on new file creation, for instance)?

The main idea was to make it simpler for users as many people don't go for the plugin yet and they should. But I guess it's their loss... In any case, I leave it up to you what you find useful to implement over time.

Cheers

[danielo515]

My idea was about reducing the Templater lines and asking Modal Forms to do more. But I agree you don't want to write a new Templater inside Modal Forms.

Yeah, me too. Modal Forms is currently capable of doing this, its only requirement is that you provide the value for a field. That's why I thought about including a hidden field that will let you do that. But I'm not sure about the implications

Another alternative will be that the method asFrontmatterString accepts an option of 'extra-fields' that will be present in the output, so you can have everything in one single line.

<% "---" %>
<%*
  const modalForm = app.plugins.plugins.modalforms.api;
  const result = await modalForm.openForm("example-form");
  tR += result.asFrontmatterString({ extraValues: { created: new Date().toDateString() } });
-%>
<% "---" %>

Also, what I meant above is need to add --- fences... if Modal Forms use processFrontmatter behind the scenes, will it not create the YAML fences if they don't exist (on new file creation, for instance)?

This is intentional. Many times I want to include some manual parts in the template, and the fences should wrap the whole block, not only what the result will produce. This gives you greater flexibility of where and how you place the generated text. Also, no, by default obsidian does not generate the fences. I can add an option to include the fences though. vx

[aaachen]

Not sure if my use case falls into this category, happy to open a separate issue to track otherwise

I have a form that I want to list dv values from the current file. It's intended to be wired up with quickadd. The idea of the dv query is something as follows:

${currentPage}.Milestone

I tried doing dv.current() but the plugin reports it's not a supported function, so I was wondering if I can pass the current file name as a variable and use dv.pages, letting modal form interpret the template string

// modal form replaces pathToCurrentFile from options
dv.pages('"${pathToCurrentFile}"').Milestone

In the quickadd macro script I'd pass the ${pathToCurrentFile} with = dv.current().file.name If there pointer to existing alternative that'd great too! (Inline form seems to be the way)

[aaachen]

I think my use case can be generalized further as "variables that may be used by the form renderer", with this you can build a form like, say, static options for multiselect that is specified by a variable provided at runtime (caveat would be type checking I suppose)

This is definitely a more niche feature so just throwing it out there. Since I just found out about inline form it doesn't block me, it'd just make modal form even more op :)