Binding Transformation [message #1743124] |
Mon, 12 September 2016 08:10  |
Eclipse User |
|
|
|
I've written three bindings now and all three of them could have used a transform where the transformation came from the source equipment itself.
Simple example: a multizone audio system. Each zone will have a name and presumably the UI will allow the user to pick a zone to control. From a UI perspective, it would be nice to allow the user to pick from a list of zone names rather than zone numbers.
The mappings transformation can easily do this. However, the map file is not the official 'source' of those mappings - it's the source equipment and having it duplicated in a file will inevitably lead to a mismatch (especially if those names can be changed by the source equipment via keypads) and increases the amount of maintenance that needs to be done in large, complex automations.
I'd like to purpose a way for a mapping transformation to come from the binding itself. Do you all think it's a good idea?
If so, I don't know the backend code well enough but it seems that it can partly be done by implementing the TransformationService. But I have no idea how the registration of such a service occurs nor if it can be more generalized.
|
|
|
Re: Binding Transformation [message #1743227 is a reply to message #1743124] |
Tue, 13 September 2016 08:37   |
Eclipse User |
|
|
|
Hi Tim,
The TransformationServices are meant as a tool for the user to adapt the output of a binding to their needs, if that isn't what they need. TransformationServices should therefore NOT be used by the bindings themselves - instead, the bindings should directly spit out the expected values. So instead of having a Number-channel for zones, there could be a String-channel that directly sends the zone names as a state.
This doesn't solve the "present the user a list of options" problem though (although I do not see how this is solved through a map transformation file..?). This is usually done through StateDescriptionProviders. There is one implementation (ChannelStateDescriptionProvider), which takes this information from the thing type, so instead of defining your thing types in xml files, you could implement a ThingTypeProvider, which dynamically provides this information. This isn't really a good fit either, because your options do not depend on the thing type (=class), but on the thing (=instance) itself. Since the StateDescriptionProvider interface refers to items, this must not be implemented within bindings, so this isn't an option either. We might discuss to adapt the ChannelStateDescriptionProvider implementation to also optionally query ThingHandlers whether they want to provide specific state options - this would probably the best way to support your requirement. Does anyone have any other ideas/suggestions?
|
|
|
|
|
|
Re: Binding Transformation [message #1744164 is a reply to message #1743469] |
Fri, 23 September 2016 01:17  |
Eclipse User |
|
|
|
This isn't really an option, since bindings are not supposed to mess with user configuration files - this would be a break of the architecture. Also, the "conf" folder is considered to be read-only, the runtime might not even have permission to write into it.
|
|
|
Powered by
FUDForum. Page generated in 0.02786 seconds