Change Details

If the params were stored in a list instead of an object we wouldn't need to maintain a separate paramOrder variable. Problems with the current setup: * Anyone editing the JSON by hand has to know the param order is stored separately, and could try re-ordering the object instead. By-hand edits may be common for bulk changes. * JS clients do not guarantee to preserve key order when en/decoding JSON so just opening and closing the TemplateData dialog could result in a massive dirty diff with all the params being re-ordered. In order to support a new format we would need to probably add a version attribute.

If the params were stored in a list instead of an object we wouldn't need to maintain a separate paramOrder variable. Problems with the current setup: * Anyone editing the JSON by hand has to know the param order is stored separately, and could try re-ordering the object instead. By-hand edits may be common for bulk changes. * JS clients do not guarantee to preserve key order when en/decoding JSON so just opening and closing the TemplateData dialog could result in a massive dirty diff with all the params being re-ordered. * Fixing key names would be trivial. Currently it is broken: T127969 In order to support a new format we would need to probably add a version attribute.

If the params were stored in a list instead of an object we wouldn't need to maintain a separate paramOrder variable. Problems with the current setup: * Anyone editing the JSON by hand has to know the param order is stored separately, and could try re-ordering the object instead. By-hand edits may be common for bulk changes. * JS clients do not guarantee to preserve key order when en/decoding JSON so just opening and closing the TemplateData dialog could result in a massive dirty diff with all the params being re-ordered. * Fixing key names would be trivial. Currently it is broken: T127969 In order to support a new format we would need to probably add a version attribute.