Add a FormatsProvider interface to ecschema-metadata

[hl662]

To update the quantity formatting of values displayed on a frontend app, currently you would have to override formats used within the QuantityFormatter in core-frontend. Then, tools and frontend components that use formats through the QuantityFormatter would be able to reflect the changed formats. However there are cases where some components might not use formats via QuantityFormatter.

From @grigasp:

Regarding quantity format overrides... For some reason the first thing I thought of was unit system, which should work. But format overrides is a different beast - there are 2 ways to format property values:
1.Using quantity formatter on IModelApp.quantityFormatter
2.Using formats that we get from schema
Since all properties in property grid are based on schema, we use schema-based formatting, which means we don't take into account any overrides set on IModelApp.quantityFormatter.
When @saskliutas started working on editors, we had some discussions with schema guys about having a single API for finding unit formats, taking into account: ECProperty kind of quantity, default formats, format overrides, etc.

@diegoalexdiaz on formats from schemas:

During schema development, our mindset regarding format settings captured in KoQs defined at schema-level is that those are "defaults" / fallback settings. The decision at schema-level regarding KoQs is "what properties are formatted together". Our expectation all along has been that users (not getting into what personas in this statement) will be able to change (override) those default format-settings per KoQ without having to change any schema.

There may be a need for a FormatsProvider, just like a UnitsProvider, that let's users decide what type of formats to use, and allow a way to replace formats used during runtime, separate from what's currently done in QuantityFormatter with format overrides.

One goal this interface would achieve, is that formats loaded from a FormatsProvider would be independent from format overrides, hence should not be affected when clearing format overrides

TBD on methods to expose in this new interface

[grigasp]

Adding some details from our side regarding what we expect from the API.

The primary thing we need for rendering formatted properties is FormatterSpec - it's needed for read-only and read-write cases. For the latter we also need a ParserSpec. At the moment we have two different ways to find/create them:

• For formatting schema-based properties, we use SchemaContext and UnitsProvider to find appropriate format, based on given KindOfQuantity name and active unit system. In case KoQ doesn't specify a format for the active unit system, we allow consumers to provide us a default formats map that we can fall back to. Implementation is here.

• For formatting arbitrary properties on the frontend (e.g. for tool settings), we use IModelApp.quantityFormatter. Implementation is here.

What we would like to have is some kind of unified API that returns us the two specs, taking into account everything:

1. Format overrides (these should probably be combined from different sources, e.g. organization / itwin / imodel / user ones).
2. KindOfQuantity, if the property is based on schema.
3. Fallback formats.

Of course the above should be based on the active unit system. And we need some event that notifies us whenever the formats / parsers change, so we can request for updated specs.

[hl662]

The primary thing we need for rendering formatted properties is FormatterSpec - it's needed for read-only and read-write cases. For the latter we also need a ParserSpec.

With both these classes in mind, I think the FormatsProvider should provide FormatProps objects then - FormatterSpec and ParserSpec objects can be created with one FormatProps. Different implementations of a FormatsProvider should handle the different cases surrounding Format overrides, schema based Formats , and fall back formats. To me, those sounds like 3 different implementations, that perhaps could be registered onto the IModelApp.quantityFormatter (with the fall-back maybe being the default)

the above should be based on the active unit system

Are you looking for something similar to _overrideFormatPropsByUnitSystem? That is, a FormatsProvider should know which formats are associated with which unit system?

we need some event that notifies us whenever the formats / parsers change, so we can request for updated specs.

We'll definitely look into defining events that tools/ frontend applications can subscribe to. This does tie back to my point above with IModelApp.quantityFormatter. Within there, we have methods like clearing/setting format overrides, or setting unitsProvider that I believe within those methods, should also emit whatever event we define for the FormatsProvider. So there's an argument that IModelApp.quantityFormatter should have an optional FormatsProvider field, for such cases.