Issues with Dynamic Form

Get Help
1

I am having issues getting my dynamic forms working to hide select options. I have proven that the dynamic forms are enabled, as the dynamic_forms.js is included, and I can use the data-set-<id> works ok. Is there any way to turn on some debugging on what is going on in the dynamic forms?

In looking into this I cloned the git@github.com:OSC/bc_osc_jupyter.git repository into my dev directory and then did a command line to switch out ascend to boreal(my cluster name):
grep -r -l ascend | while read i; do sed -i -e 's/ascend/boreal/' $i;done
and then loaded it up, the form still has all the options in the Node type selector.

Any thoughts on what I can do to enable the hisign of selections? or debug the issue at a java-script level?

2

I’d recommend using an editor and not sed when making changes, because now we both don’t know what’s in that form and working off a sed command is needlessly complicated.

There’s no debugging bit to switch on for dynamic forms.

My guess is you just need to tinker some, use an editor to do this. For JS the way to debug would be the usual F12 then use the dev console to log any statements and see what’s going on. But, without an actual config file to look at it’s very hard to debug or guess at what is wrong.

3

sed is an editor by definition, it is a stream editor for filtering and transforming text (from the man page). And I was very specific to give the formula for getting the exact code for the form. You clone to Git repo, and run a simple command. the bash command around sed is more complicated than the simple substitution done by sed. If it helps, you can goto github.com:OSC/bc_osc_jupyter.git and just assume I am on the ascend cluster.

Acknowledged.

First of all, F12 runs System Preferences on my Mac and locks the screen on my Linux box, so Windows-based Function keys won’t help.

Second, this is what I had been doing for the two days before I asked the question, I was more hoping for information on how what to be looking at, and maybe how to debug it better.

4

I found that reverting this change in the code makes dynamic forms work properly on a single-cluster config with cluster-based dynamic forms:

@jeff.ohrstrom any comments on why it needs to be a fixed value?

5

I put in the ticket why I believe it needs to be a fixed value.

As a work around, you can specify cluster in the form instead of outside of it. The code will recognzie there’s a cluster attribute and not create the fixed attribute instead using the one you’ve supplied.

Here’s an example of how to do this that I hacked around on and got it working.

form:
  - queue
  - cluster
attributes:
  cluster:
    widget: hidden_field
    value: owens
  queue:
    widget: 'select'
    options:
     -  ["oakley queue", data-option-for-cluster-owens: false]
     -  ["owens queue", data-option-for-cluster-oakley: false]
6

I do something similar for a Jupyter app that uses the linux host-based adapter to submit to some big file servers outside of slurm, but I just do the following like its a normal form field:

attributes:
....
  cluster:
    widget: "select"
    label: "File Server to use"
    help: "Select which fileserver you want to run on"
    options:
      - ["File server 1", "Fileserver1"]
      - ["File server 2", "Fileserver2"]
...

I then have cluster.d configs for each file server.