At the request of Matthijs Beekman I place this request here on the forum. Perhaps more customers are concerned about this. Maybe others already have a solution/workaround for this.
Description of the limitation and why it is relevant to address
As a developer I want to explicitly specify a unit for parametrization fields so that my code has less clutter and is more robust.
I think this is relevant for the VIKTOR platform because it removes boring code, allows for quicker development. It could also help prevent conversion bugs, making the platform more trustworthy for end users.
Current issues
Because external integrations don’t necessarily have the same unit as our parameters, conversions now appear in different places in our code:
floor_thickness_m = self.params.geometry.floor.thickness * 1e-03 # [m]
Sometimes those conversions are forgotten to add to the code, causing bugs.
Or sometimes a product owner / stakeholder wants a parameter to be changed from mm to m. Maybe great for UX, but it introduces quitte some code changes and more chances of bugs, leading to extra costs and lowered quality.
Submitter proposed design
Explicitly add “units” to the platform.
I’ve dealt with QUDT in the past and was a fan of it. It is an (extensive) way to record units (and more) in linked data. It also facilitates conversions between units. E.g. with quantity type “Temperature” it is easy to switch between Kelvin, ºC and ºF. But also at Length between meters, inches and millimetres.
That would allow for cleaner code like:
floor_thickness_m = self.params.geometry.floor.thickness.convert_to(qudt.unit.M)
You could then explicitly add a unit in the parameterization. Maybe even with a different ui_unit (similar to the current ui_name)
geometry.floor.thickness = NumberField(
"Floor thickness",
unit=qudt.unit.M,
ui_unit=qudt.unit.MilliM, # millimetre
# suffix="mm", << Made redundant by qudt.unit.MilliM.symbol
)
Added benefit: Automagical suffix parameter
As seen above, this also makes the suffix parameter less important, as it is automatically populated from the specified unit.
Added benefit: Automagical unit conversions for external integrations
When the platform itself can handle units, conversions for external integrations may even be omitted altogether. E.g. when a dfoundations.RectPile() is called with a NumberField param, the platform automagically convert the param’s value into meter.
Current workarounds
We could make use of Pint of Sympy’s physical quantities in our own code. Maybe even extend the NumberField and IntegerField classes. But that would probably only partially fix the issue. E.g. would this work with with Table and DynamicArray containing such an extended class?
I think it has more added value for the platform when this is a built-in functionality. It would prevent us developers all invent the same thing.