Revision history [back]
OpenStudio Measure with long list of inputs -- best practice
I'm writing an OpenStudio measure with a long list of options for many of the input parameters. Initially, I tried to use a secondary file to host all the constants to keep things tidy but found importing parameters into the measure.rb file resulted in the OpenStudio application not populating my input dropdowns (although I could see them in the measure.xml ?) So I tried looking through other measures and found most folks just kind of listed them all out in the measure.rb file. Is there no better best practice?
MCVE directories for a working and broken example of what I mean can be found here:
You will see both measures populate the choice argument with a module called MyConstants:
choices_os_vector = OpenStudio::StringVector.new
option_list = MyConstants::CHOICE_LIST
option_list.each do |option|
choices_os_vector << option
end
The only difference is that working example has the module inside the measure.rb file while the broken example references the module from a separate file called my_choice_constants.rb.
I would much rather have this list of inputs reference a dynamic reference that updates with something like the OpenStudio Standards gem rather than have to update it in two places.
OpenStudio Measure with long list of inputs -- best practice
I'm writing an OpenStudio measure with a long list of options for many of the input parameters. Initially, I tried to use a secondary file to host all the constants to keep things tidy but found importing parameters into the measure.rb file resulted in the OpenStudio application not populating my input dropdowns (although I could see them in the measure.xml ?) So I tried looking through other measures and found most folks just kind of listed them all out in the measure.rb file. Is there no better best practice?
MCVE directories for a Measure I'm working on and broken example of what I mean can be found here:how I had to use a module inside of measure.rb to get it to work:
Link to working and broken measureHow I'm referencing a module inside measure.rb- Module it's referencing
You will see both measures populate the choice argument with a module called MyConstants:
choices_os_vector = OpenStudio::StringVector.new
option_list = MyConstants::CHOICE_LIST
option_list.each do |option|
choices_os_vector << option
end
The only difference is that working example has the module inside the measure.rb file while the broken example references the module from a separate file called my_choice_constants.rb.
I would much rather have this list of inputs reference a dynamic reference that updates with something like the OpenStudio Standards the OpenStudio gem rather than have to update it in two places.
OpenStudio Measure with long list of inputs -- best practice
I'm writing an OpenStudio measure with a long list of options for many of the input parameters. Initially, I tried to use a secondary file to host all the constants to keep things the measure file tidy but found importing that if I imported parameters into the measure.rb file resulted in the OpenStudio application did not populating appear to populate my input dropdowns lists when I did this (although I could see them in the measure.xml ?) So I tried looking through other measures and found most folks just kind of listed them all out in the measure.rb file. Is there no better best practice?
Measure I'm working on and how I had to use a module inside of measure.rb to get it to work:
I would much rather have this list of inputs reference a dynamic reference that updates with the OpenStudio gem rather than have to update it in two places.