Best practices in storing chunks of external code

Question

I am building a wrapper to a load-testing tool that will take configuration and scenario files as yaml and build a large, unwieldy xml file which will be destroyed when it is no longer needed.

A sample yaml file would look like this:

# basic.yml
config:
  ip: 127.0.0.1
  rate: 1 
  maximum: 10
  iterations: 75
  email: foo@bang.com
  repeat: true

scenario:
  - wait 5
  - ping 7
  - wait 5

The xml contains a host of data that is specific to the underlying tool being wrapped but which never needs to be seen by an end user.

For example, the header is as

<send retrans="500">
  <![CDATA[
   <!-- 25 lines of specific configuration that will never change -->
  ]]>
</send>

<recv response="100" optional="true"/>
<recv response="180" optional="true"/>
<recv response="183" optional="true"/>
<recv response="503" optional="true"/>
<recv response="200" rrs="true" rtd="true"></recv>

where literally none of the information in this segment needs to ever be altered. In fact, nothing in the config section of the yaml effects the xml. What does effect the xml is the scenario. We can think of the scenario as a domain specific language (dsl) in which wait 5 signifies that we must add

<pause milliseconds="5000"/>

after the header, and ping 7 signifies that we must add

<send retrans="500">
  <![CDATA[

    <!-- 12 lines of specific configuration that will never change -->

    Signal=7   <!-- passed from yaml -->

    <!-- 6 lines of specific configuration that will never change -->

  ]]>
</send>

followed by a final

<pause milliseconds="5000"/>

before another 30-40 lines of specific xml that will never change.

My Approach

I plan to use Ruby to do this implementation, but that is irrelevant to my question, which is about best practices in generating xml from a dsl template. I am thinking of holding my xml "units" in a subdirectory as text files:

- header.txt
- wait.txt
- ping.txt
- footer.txt

Where wait.txt would look as

<pause milliseconds="#{time}"/>

and my parser would pull the text file, use string interpolation to insert the time pulled from the yaml before appending the message to the xml file being generated. We could think of the dsl to generate an xml file for this yaml file as

header
wait 5
ping 7
wait 5
footer

Question

What are best practices in using yaml to generate xml? Is there a more "rubyish" way to store the underlying xml components? Am I missing opportunities in using the xml format?

Paul Sweatte · Accepted Answer · 2018-09-11T14:07:32.067

The best practice is to make sure you can generate YAML from XML as well as XML from YAML:

This proposal prescribes an isomorphic rendering in YAML of a subset of the TOSCA v1.0 XML specification ensuring that TOSCA semantics are preserved and can be transformed from XML to YAML or from YAML to XML. Additionally, in order to streamline the expression of TOSCA semantics, the YAML rendering is sought to be more concise and compact through the use of the YAML syntax.

The more Ruby-ish way to structure the files would be as .xml files in a metadata or support directory.

References

Best practices in storing chunks of external code

My Approach

Question

1 Answers1