A form.yml question

Get Help
1

Hi All,

  1. Is there a way to debug, or lint form.yml syntax? Sometimes I manage to somehow mess one of the “select” widgets that then ignores all the options and comes as a text input.

  2. is it possible to inline files in form.yml or form.yml.erb? Some code there, like partition selection, is very repetitive and can be shared between different apps.

Thanks!

Grigory Shamov
University of Manitoba

2

Interesting you should ask these two things given some recent changes we’ve made.

  1. We’ve actually done some work on the backend to handle the linting for those selects for this type of problem and will likely be in the next release. The relevant PR: Catching missing select options in app yaml. by Oglopf · Pull Request #1455 · OSC/ondemand · GitHub

  2. For this, I believe some changes we are making with the JS will handle this. Basically when you make certain selections on the page, you want other form fields to react and offer choices based on that selection. This is something we have on the Projects page and are working towards building out currently. automatic js handlers for hidden form items · Issue #1432 · OSC/ondemand · GitHub

If you have any more thoughts or any of these aren’t quite what you had in mind just let us know.

3

  1. Ok, it sort of was me, but. Turned out that I was trying to make “select” out of a pre-defined widget, bc_queue. Which wants to be a text field. That was silly of me, I should have paid attention to the documentation that does list the pre-defined form items. But may be it should be more verbose: should a pre-defined widget fail with a message if one tries to re-define it, rather than silently ignore the form’s options?

  2. Thanks for the JS hint, it is useful, and I am implementing it now. My question was different: I find that things like nodetypes, partitions etc. may belong to the cluster rather than individual apps. So there is one setting of partitions/walltimes/etc. I found myself copying and pasting into every apps’ form.yml. It looks as a natural candidate for something like %include, no?

4

You can define variables in the cluster’s .yml file in /etc/ood/… and refer to those from your applications, if that helps.

5

I guess that helps. But for form help: and such I will still have to copy paste.

6

A step beyond this, you can actually make initializers that have some more advanced functionality. I have a special initializer on one cluster set in: /etc/ood/config/apps/dashboard/initializers

require 'open3' 

class CustomQueues ### GET PARTITIONS FOR THIS USER ###
  def self.queues
    @queues ||= begin
        sinfo_cmd = "sinfo"
        args = ["--noheader","-o=\"%R\""]
        @partitions_available = []
        o, e, s = Open3.capture3(sinfo_cmd , *args) 
        o.each_line do |v|
          @partitions_available.append(v.gsub(/=\"(\S+)\"|=\"(\S+_p)\"/, '\1'))
        end
      @partitions_available
    end
  end
end
CustomQueues.queues

This defines a function to populate all of the partitions a user has access to that I can call on the fly to populate a partition select widget.

This is then whats in my form.yml.erb to generate the select box list of available partitions.

  queue:
    label: "Partition"
    widget: select
    options:
      <%- CustomQueues.queues.each do |g| -%>
      - "<%= g.strip -%>"
      <%- end %>
    cacheable: false
7

You could also define a widget in a file and use something like

<%= File.read("/etc/ood/config/apps/dashboard/batch_connect/partials/reservation.yml").indent(2) %>

In your form.yml.erb to “paste” the contents as it were.

8

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.