fix labelTemplate #282
fix labelTemplate #282
Conversation
This change fixes two issues: - The label template was only applied, if there was an explicit label that differs from the name. It is now always applied, using the name as the default label. - The label template was not applied on properties in `fragments`. This is addressed by moving the schema transformation after resolving the schemas. So far the labelTemplate transformer was the only transformer applied in `FeatureProviderSqlData` while all the other transformers are applied in `FeatureProviderSqlFactory`. In addition, after the schema resolver transformation has been applied, the fragments are no longer used and can be removed from the data.
azahnen
left a comment
azahnen
left a comment
There was a problem hiding this comment.
Thanks, moving the resolving to the factory makes sense.
I think we should document it, since it should be stable now. Maybe we should we also add a default value?
|
I will document it and then also add an ldproxy issue that we can reference in release notes. The default would be |
document `labelTemplate`
|
@cportele I actually meant a default value containing the unit. Since most people don't use units and it only affects the labels, I would not deem this a breaking change. And it would make using units simpler and more intuitive. |
|
@azahnen - Since we and also others have sometimes included the unit manually in the label, this would then result in labels like |
|
@cportele Ok. |
This change fixes two issues:
fragments. This is addressed by moving the schema transformation after resolving the schemas. So far the labelTemplate transformer was the only transformer applied inFeatureProviderSqlDatawhile all the other transformers are applied inFeatureProviderSqlFactory.In addition, after the schema resolver transformation has been applied, the fragments are no longer used and can be removed from the data.
This is an undocumented option. Shouldn't the option be documented?
Closes ldproxy/ldproxy#1259