Adding a dropdown (or multiple?) allowing to change the querry results dynamically.
For example, this would make it possible to render a table, with a dropdown to select a project status and the table would update accordingly.
```query
project
where status = dropDown(statusList)
render all [[path-to-template]]
```
I’m not sure if this could be achieved with space script. But definitely above my skill level in case it is…
This is definitely not reasonably possible right now. Perhaps you can do something extremely intricate with space script, but I wouldn’t recommend it.
This is an interesting use case though, and will take it into account as I explore some ideas in the Space Lua space.
Let me throw in some conceptual ideas. Not happy with them, but interested in feedback. Let’s say that we introduce the concept of a “page variable”, let’s say (although we could also just use front matter for this):
```page-vars
selected_status: "done"
```
And then have a way to bind a widget to it:
Select status: ${drop_down("selected_status", {"to do", "doing", "done"})}
Where changing that drop down, would inline update the variable value in the page-vars block.
Then you could have the ability to use that page variable in your query, you’d be able to get there, right?
Again, just conceptual thinking here. Not committing to anything.
Oh yes, please. If something like this turned out to be achieable i’d use it a lot.
OT: I dream of Markdown parser and document model extensibility via custom scripting…
Checklist (we have it already):
- [x] checked
- [ ] unchecked
Selection:
- ( ) unselected
- (x) selected
- (x) selected 2
- ( ) unselected
Colapsible lists:
- item 1 with colapsed sublist
- item 1
- item 2
+ item 2 with expanded sublist
- item 1
- item 2
And what I would love the most to have are inline checkboxes:
This is some paragraph of dummy text with a checked checkbox [x] inside
it and one more checkbox [ ] unchecked.
And, of course, everything would remember it’s state (and edit itself, as it is in case of the normal checkboxes we have).
It feels unnecessary to go with a specific section for it, a subsection of the frontmatter would be more suited for it.
I was thinking more of something self contained within live query/template. However, the general workflow you describe seems well thought out. What I like about it, is that it can mostly be done already with space-script except using a push button (command link) instead of a drop down. So we’re only missing the drop down…
It seems adding the ability to create drop down menu that handles the selection of a variable and trigger a function on selection would allow lots of flexibility and is likely to bring other use cases.
Could schema help here? What about rendering frontmatter (or maybe other yaml code blocks too) differently to match that schema?
This isn’t currently possible, but what I’m thinking would look like this schema:
schema:
properties:
status:
type: string
enum:
- active
- todo
- completed
required:
- status
And then in frontmatter of a page:
---
status: todo
---
todo could be rendered as text by default, but if you click on it, it could turn it into a dropdown list based on the schema.
Enums would be a dropdown list and boolean a checkbox; everything else the same as it is now
I would rather have the possibility to put the dropdown anywhere, not only in the frontmatter.
What if I have a long document with a table at the end? I don’t want to scroll back to the top to change the filtering in the frontmatter.
I would say best scenario would be next to the query buttons or in the corresponding column header.
But for the sake of flexibility, something similar to the command link but generating a dropdown instead of a push button seems like a good balance.
