Add markdown widget for interactive app forms

[robinkar]

Allows inserting arbitrary Markdown into the app forms through the form.yml files.
The largest use case for us, which I've also seen others request on Discourse (e.g. here and here), would be use this to create headings/sections in the app form.

For example, the following form YML:

attributes:
  slurm_partition:
    label: "Slurm Partition"
    widget: select
    options:
      - interactive
  cores:
    label: "Memory (GB)"
    widget: number_field
    value: 2
  header_resources:
    widget: markdown
    value: |
      ---
      ## Resources
  header_settings:
    widget: markdown
    value: |
      ---
      ## Settings

form:
  - slurm_partition
  - header_resources
  - cores
  - memory
  - header_settings
  - bc_email_on_started

would produce the following form:

This is not fully ready for merging (e.g. missing tests), but I'm submitting this to check whether this could be a potential solution/approach to this feature. Potentially fixes #1806.
I added serialize? for SmartAttributes since it would make sense to not store the value of this in any user_defined_context.json or saved settings file (bc_saved_settings), but .select(&:serialize?) should probably be refactored into a function if this approach is fine.

[johrstrom]

I'm not sure about this implementation. Given that we have to .select(&:serialize?) everywhere and can't just pull the attributes tells me there's something amiss here. IDK it just adds complexity to the downstream consumers who have to always remember to filter these out.

That said - I get why you did it. We can't just add another property like header because bootstrap_form gem actually generates the entry, and we can't pass a block to it to add extra elements.

[robinkar]

I made an attempt at improving it somewhat, although the core idea remains the same.
It seems like the distinction between the different attributes need to be made somewhere, and already exists to a certain extent with fixed attributes being handled differently, but the new logic here (i.e. serialize?) is now more limited to SessionContext.
The way I see it is that there are attributes that affect the execution of the job and are visible in the form (serializeable and visible, user-configurable), attributes that affect the execution of the job, but are not visible (fixed (non-serializable) and invisible, not user-configurable), and attributes that do not affect the execution of the job, but are visible (non-serializable and visible, introduced with this PR).
Downstream consumers would need to select the correct attributes depending on purpose, i.e. BatchConnect::App.attributes (all attributes), vs SessionContext.attributes/each (serializable only) vs SessionContext.each_form_attribute (visible attributes for form). A larger refactor would probably make these distinctions more clear, but I am not sure at the moment what that would look like.
Suggestions on how to improve this are much appreciated.

[johrstrom]

Suggestions on how to improve this are much appreciated.

It seems to me like we need catch the output here and maybe prepend it.

Something like this in create_widget. As you elude to, there are UI specific stuf, like label, and so header can be similar to that. Where we render the form field, but then prepend the header if it exists.

rendered =    case widget
              when 'select'
                form.select(attrib.id, attrib.select_choices(hide_excludable: hide_excludable), field_options, attrib.html_options)
              when 'resolution_field'
              # ...
              end

# may not even need the if block because nil won't render anything anyhow.
if attrib.header.nil?
  rendered
else
   header =  OodAppkit.markdown.render(attrib.header.to_s).html_safe
   "#{header}#{rendered}"
end

[johrstrom]

Looks like it's been some time since you opened this. Is this still on-going? It seems I left a comment, but I haven't seen any updates. Are you waiting on me for something?

[robinkar]

Looks like it's been some time since you opened this. Is this still on-going? It seems I left a comment, but I haven't seen any updates. Are you waiting on me for something?

Sorry for stalling this, some other tasks came up and I kept postponing this.
I just pushed a version with what you suggested, which should work well enough for us.

Only thing that might need more consideration would be how it interacts with the dynamic JS, e.g. data-hide-*. Right now, the header is always visible, which is fine in our case at least. In theory it could be useful to hide the header as well if all the form elements under that category/header are hidden, but in our case I don't see it ever being hidden.

[johrstrom]

Thanks! I'll add a test around sanitize shortly while it's on my mind.