|
Re: Binding Transformation [message #1743227 is a reply to message #1743124] |
Tue, 13 September 2016 12:37 |
Kai Kreuzer Messages: 673 Registered: December 2011 |
Senior Member |
|
|
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 #1743328 is a reply to message #1743227] |
Wed, 14 September 2016 12:09 |
Tim Roberts Messages: 29 Registered: September 2016 |
Junior Member |
|
|
If you don't mind a little discussion, based on your response I'd say the transformationservice is exactly what should be used. From the users perspective (and if you don't mind me reusing your words), they want to adapt the output of the binding to the settings they have stored on their device.
The binding will still be spitting out the the correct values - it's just the binding will provide an optional implementation of the transformationservice a class that can then map those values to what the user has set in the source device.
Maybe I'm not understanding what you are getting at but think that would be a wonderful addition.
Examples (not suggesting this api - just for clarity of example):
Number Russound_Zone "Zone [RussoundMap(%d)]"
The user is saying to transform the russound zone id's via a binding supplied transformationservice that will convert the zone id's to zone names that they set on the source equipment.
[Updated on: Wed, 14 September 2016 12:10] Report message to a moderator
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03477 seconds