Load DropDown Content from yml


I’m currently a bit lost with dynamic DropDown Fields.

I currently have multiple dropdown fields and I want to load dropdown contents dynamically from a yaml file. To load info from a yaml file I created a inline ruby method. Currently I have a ruby method and an instance for every dropdown field but the action is always nearly the same. The only difference are the yml-filenames.

Poor me thought that one method with a case statement should be enough. I just have to know which drop down field called the method but I failed so far on finding out where that info hides or if it is there at all.

I give you an example:
I have two dropdown elements “dropdown1” and “dropdown2”. I have one ruby method like this:

case dropdown
whe`n “dropdown1”
when “dropdown2”

How does the method know when to fill dropdown1 or dropdown2?

you can pass parameters from the Instance to the Method (https://pemcg.gitbooks.io/introduction-to-cloudforms-automation/content/chapter3/using_schema_object_variables.html). I would create one Instance per yaml file, passing the filename to the Method and configure the dropdowns to point to the correct instance

Alternatively you can also introspect the Instance from the Method, like so:

$evm.current_namespace = sIT/Discovery   (type: String)
$evm.current_class = ObjectWalker   (type: String)
$evm.current_instance = object_walker   (type: String)
$evm.current_method = object_walker   (type: String)
$evm.current_message = create   (type: String)
$evm.current_object = /sIT/Discovery/ObjectWalker/object_walker   (type: DRb::DRbObject, URI: druby://
$evm.current_object.current_field_name = execute   (type: String)
$evm.current_object.current_field_type = method   (type: String)
$evm.root['object_name'] = object_walker   (type: String)
1 Like

Aaaaah, thank you.

I knew I missed something. You are absolutely right. Thank you very much. I bend my mind around instances before but my thoughts were if I could insert a dynamic variable into the schema with the goal to use only one instance.

But having multiple instances and only one method is perfectly fine for me.

I’ll leave the question unsolved until someone suggests a solution with only one instance and one method.

I am not sure if there is a better way…
At least if there is nothing else differentiating the two use-cases. Are the dropdowns in the same dialog (and the same button/catalog item) or are the completely separate and just happen to share the “load values from YAML”-feature?

Do you have specific reason, why you don’t want to use multiple Instances? Could you elaborate more on your use-case?

Hi there,

dropdowns are in the same dialog. I have no other specfic reason then laziness. As I wrote multiple instance are fine for my use-case but I don’t understand why $evm environment is not aware of the dialog element that called the instance. Why do I have to create multiple instances when all I want to know is which dialog element called the instance? It’s a shortcoming to me, simple as that.

I assume that it is currently not possible and that my wish might lead to a feature request.

I can see, that it looks overly complicated at first, but the more I think about it, it makes a lot of sense, if you think of scaling the approach to 10s of dialogs with 50+ dynamic elements reading from YAML files.

Here is my perspective:

Suppose you have the conceptually “same” dropdown in multiple dialogs (e.g. the cost-center to pay for a given service).
If you refer to the element by name, you have to either account for every occurrence in the code, or force the cost-center-elements to have the same name (which is an additional thing to explicitly review, if multiple people are working on the code).

I also depends on how you conceptualize an Instance.
To me, an Instance is the same thing as as a function call (in the simplest case) with all the arguments statically defined. In that case, you would expect to have multiple Instances pointing at the same Method.
(Although in our Code, we mostly have a 1:1 ration)

On a very very abstract level, you can also think about the problem in terms of which part controls which.
Should the dynamic-element tell the method, what information it should fetch or should the Method limit the calling element to a couple of well defined use-cases?

Is this yaml file stored locally on the appliance? In a multi-instance environment you need to keep them in sync.