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.
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.
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
m. Maybe great for UX, but it introduces quitte some code changes and more chances of bugs, leading to extra costs and lowered quality.
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
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 )
As seen above, this also makes the
suffix parameter less important, as it is automatically populated from the specified unit.
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
We could make use of Pint of Sympy’s physical quantities in our own code. Maybe even extend the
IntegerField classes. But that would probably only partially fix the issue. E.g. would this work with with
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.