Need ability to remove boilerplate in mi-label

[rgdeen]

One of the awesome-est features of mi-label is that it will collapse out elements that have no children. This is what gives it much of its power.

But sometimes what happens is, you have very complex decisions about whether to include elements or not, and then some basic boilerplate. The boilerplate keeps the element in even though there are no other children. It’s not practical to replicate all those checks just to get rid of the boilerplate. So if we had some symbol that indicated “keep this element if you have other siblings but don’t let it prevent you from collapsing out the element if not” that would be extremely helpful.

For example, this fails validation:

          <geom:Articulation_Device_Parameters>
            <geom:device_id>RSM</geom:device_id>
            <geom:device_name>REMOTE SENSING MAST</geom:device_name>
          </geom:Articulation_Device_Parameters>

because it doesn't have any substantive children (angles, temperatures, etc). in this case, all the children collapsed away because they were NULL in the input (it was some very weird data). If we could get the whole Articulation_Device_Parameters to collapse away too, that would be great... but the boilerplate name prevents that.

One way to do this might be to enclose such "weak" children in double <<>> or in [] or some such. So the template might look something like:

          <geom:Articulation_Device_Parameters>
            <<geom:device_id>>$ADP_ID<</geom:device_id>>
            <<geom:device_name>>$ADP_NAME<</geom:device_name>>
            #addDeviceAngles()
            #addDeviceComponentStates()
            #addDeviceTemperatures()
          </geom:Articulation_Device_Parameters>

etc. Or pick your own syntax. If any of the macros expand to something substanstive, the "weak" entries stay in (replaced by proper brackets of course). If they all go away, the weak children go away too, and along with them the rest of the Articulation_Device_Parameters group.

For simple cases, you can add the same conditional you use for the children, to the boilerplate. But even in the simple case that's a maintenance nightmare. In more complex cases like with ADP, where there are loops and many levels of nested macros, it really is not practical to repeat or remember the conditionals.

There are literally dozens of places we could use this in the current templates, and it would go a long way to making them much more readable and usable (and maintainable!!).