Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dynamic form JS data-show #3346

Open
Tracked by #2476
robinkar opened this issue Feb 8, 2024 · 5 comments
Open
Tracked by #2476

Dynamic form JS data-show #3346

robinkar opened this issue Feb 8, 2024 · 5 comments

Comments

@robinkar
Copy link
Contributor

robinkar commented Feb 8, 2024

The data-hide option in forms is quite inconvenient if you have some widget that only is available for a small number of options.
Something that would work the opposite of data-hide would be nice to have, e.g. data-show or maybe data-hide: false.

So rather than having forms like this:

slurm_partition:
  widget: "select"
  options:
    - ["interactive", "interactive", data-hide-gpu-type: true]
    - ["small", "small", data-hide-gpu-type: true]
    - ["largemem", "largemem", data-hide-gpu-type: true]
    - ["test", "test", data-hide-gpu-type: true]
    - ["medium", "medium", data-hide-gpu-type: true]
    - ["longrun", "longrun", data-hide-gpu-type: true]
    - ["gpu", "gpu"]

I would want to have this:

slurm_partition:
  widget: "select"
  options:
    - ["interactive", "interactive"]
    - ["small", "small"]
    - ["largemem", "largemem"]
    - ["test", "test"]
    - ["medium", "medium"]
    - ["longrun", "longrun"]
    - ["gpu", "gpu", data-show-gpu-type: true]

Where the gpu_type select widget would be hidden by default, and shown only for the gpu partition.

@osc-bot osc-bot added this to the Backlog milestone Feb 8, 2024
@johrstrom
Copy link
Contributor

I'd have to look into the hidden_field widget type. This may be doable if gpu-type is hidden by default. I think data-show could only work on hidden fields given everything's shown by default.

That said - #2924 covers your example for GPUs specifically which I'm trying to build underlying support for in OSC/ood_core#825

@robinkar
Copy link
Contributor Author

robinkar commented Feb 8, 2024

The GPU type field here would be a dropdown, while I think the hidden_field is always a textbox (unless there is a way to make it a dropdown I have missed).

This would also be useful beyond this case with GPUs, for example with reservations where some reservation might not be available for all (most) accounts (i.e. show reservation field for some account).

@johrstrom
Copy link
Contributor

OK I made #3348 for auto reservations.

I'm not really sure how to implement this given everything is shown by default. I'd guess we'd need to collect all the data attributes and determine if there's only 1 state it can be shown in and react off of that.

But auto_gpus and auto_reservations may make the whole thing moot.

@robinkar
Copy link
Contributor Author

robinkar commented Feb 8, 2024

I think it could be fine to have some attribute be set for the GPU type field to toggle the behaviour, although some automatic detection would of course be better.
So something like:

gpu_type:
  widget: "select"
  hide_by_default: true
  options:
    - a100
    - mi250

I'm not sure how useful an auto_reservation or auto_gpus field would be for us, as right now as we are not using the auto_ attributes (mostly due to some missing features).

@johrstrom
Copy link
Contributor

I'm not sure how useful an auto_reservation or auto_gpus field would be for us, as right now as we are not using the auto_ attributes (mostly due to some missing features).

Well I would say that the intent is to be feature complete. Please let me know through tickets what's missing and I'll try to complete it. A test case for the expected behavior of you'd want would be best with perhaps some test fixtures we can test against.

We don't expose reservations or queues to customers, so it's a bit tough for me to test against our own sacctmgr or sinfo output.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants