On 03/12/2020 03:48, Steve McIntyre wrote:
> Thomas Goirand wrote:
>> Otherwise, what would be the way to describe a tree?
>
> I'm playing with ideas so far, let's see shortly. :-)
I have an idea to do this without new types but I'm not sure how
feasible/suitable it is. I'd define the template names to be a tree and
ask the frontend a bundle of them at the same time, where the frontend
would render these in a tree if it understands the tree structure or
show multiple questions if it does not.
For some example templates:
Template: foo/bar
Type: multiselect
Choices: a b c
Template: foo/bar/a
Type: select
Choices: 1 2
Template: foo/bar/b
Type: multiselect
Choices: x y z
Template: foo/bar/b/x
Type: select
Choices: d e
(This would not work if it's being mapped to the filesystem in some way,
foo/bar would impossibly need to be both a file and a directory. But it
may be mitigable by using e.g. foo/bar:b, foo/bar:b:x instead of the
last two templates.)
We could call something like:
db_input foo/bar
db_input foo/bar/a
db_input foo/bar/b
db_input foo/bar/b/x
db_go
Then, frontends could arrange them however they want it best. They could
show/hide child choices with a frontend-specific mechanism:
foo/bar: foo/bar: foo/bar: foo/bar:
[ ] a [ ] a [ ] a -> [ ] a
[ ] 1 [ ] 1 [ ] 1 [ ] b
[ ] 2 [ ] 2 [ ] 2 [ ] x
[ ] b -> [ ] b [ ] b [ ] d
[ ] c [ ] x -> [ ] x [ ] e
[ ] y [ ] d [ ] y
[ ] z [ ] e [ ] z
[ ] c [ ] y [ ] c
[ ] z
[ ] c
(I thought of using selection to show the children, but the grub2's
whole-disk-vs-partitions concern applies to that as well.)
Alternatively, things would fallback to individual questions if the
frontend can't recognize that we wanted a tree:
foo/bar: -> foo/bar/a: -> foo/bar/b: -> foo/bar/b/x:
[ ] a [ ] 1 [ ] x [ ] d
[ ] b [ ] 2 [ ] y [ ] e
[ ] c [ ] z
(One problem about this fallback would be asking too much questions for
localechooser, e.g. one question for each language)
