Sitemap YAML serialization and parsing#5482
Conversation
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
Signed-off-by: Mark Herwege <mark.herwege@telenet.be>
|
|
I also like the short form if there is only one condition. |
|
Rather than label => text + format + textColor + valueColor, I will change to text => label + labelColor + valueFormat + valueColor. |
|
@lolodomo, for video encoding, does it matter if the encoding value is lower or uppercase? The documentation says |
In the yaml item definition we have the So how about text:
label: MyLabel
format: "%d"
labelColor: ... # <-- should be label rather than text because it applies to the thing configured under "label"
valueColor: ...Do you think it makes sense to not allow the short form? |
visibility:
- and:
- item: DemoSwitch
operator: ==
argument: "ON"Why is the visibility:
and:
- item: DemoSwitch
operator: ==
argument: "ON"or the short form visibility:
item: DemoSwitch
operator: ==
argument: "ON" |
textColor:
- and:
- operator: <
argument: "50"
value: green
- and:
- operator: <=
argument: "75"
value: orange
- value: redI find this very hard to read and understand. I also don't think the textColor:
value: red
conditional:
- operator: <
argument: "50"
value: green
- operator: <=
argument: "75"
value: orange |
I don't understand this one. Look at the DSL code: This is just sequence dependent or. And But how would it look for AND? That's what I was trying to discuss. |
Yes - the idea was that # convenience for
# labelcolor=["red"]
textColor: red# labelcolor=[< 50="green", <= 75="orange", "red"]
textColor:
- color: green
condition:
operator: ''<'
argument: "50"
- color: orange
condition:
operator: <=
argument: "75"
- color: red
# labelcolor=[item1<50 AND item2>50="green", <=75="orange","red"]
textColor:
- color: green
condition:
and:
- item: item1
operator: '<'
argument: "50"
- item: item2
operator: '>'
argument: "50"
- color: orange
condition:
operator: <=
argument: "75"
- color: redIt's the same condition structure which we already use for visibility but with optional |
Why do you need the condition level at all in this? Can’t you just put item, operator and argument directly under color if there are not multiple and statements? # labelcolor=[item1<50 AND item2>50="green", <=75="orange","red"]
textColor:
- color: green
and:
- item: item1
operator: '<'
argument: "50"
- item: item2
operator: '>'
argument: "50"
- color: orange
operator: <=
argument: "75"
- color: redAlso, item and operator are also optional. |
DSL syntax does not define any constraint. I have not defined one in YAML. |
The UI does because it has a dropdown with the allowed values. But I will make it case agnostic. |
I will consider that: label:
label: MyLabel
format: "%d"
labelColor: ...
valueColor: ...With this short form: label: "MyLabel [%d]" |
The and is in a list because you define different rules each one with a list of conditions (and) and a value (color or icon).
Of course it should, I just explained why. |
It is exactly what I implemented yesterday evening (not yet pushed). |
|
I will enhance my sitemap example to cover one unique or multiple and condition. |
And while you are at it, what about Buttongrid with buttons, with Buttons and with a combination? |
Yes also. |
True. But we still have it in the core object representation as well. And at the moment I still have it in the UI code. It is shorter with the |
|
DSL sitemap: Equivalent sitemap in YAML: You will find short form for label, icon and labelColor/valueColor/(icon)color. |
Yes that would be my suggestion |
Completely agree. Question is if we still include it in the DSL PR, or we do it in a separate step. |
Maybe a new separate PR.
Yes, probably. |
This PR creates a new YAML format for sitemaps. This PR builds on openhab#5459 and partially replaces openhab#4945 (covering YAML). It also makes further steps towards openhab#5007 Signed-off-by: Laurent Garnier <lg.hc@free.fr>
|
Extended example with icon rules. And the YAML: |
Yes, but the idea is to have one condition mechanism or condition configuration which works the same throughout the complete structure. So every time the user writes/sees Currently there are multiple places where there are conditions are defined and I think it would be really good if visibility, where value is implicit set to true visibility:
- item: DemoSwitch
operator: '!='
argument: "ON"icons icon:
definition:
- value: material:home
item: DemoSwitch
operator: ==
argument: "ON"
- value: material:favoritecolors for label, value, icon, ... valueColor:
- value: blue
and:
- operator: <
argument: "50"
- item: DemoSwitch
operator: ==
argument: "ON"
- value: red
operator: <=
argument: "75" |
This PR creates a new YAML format for sitemaps.
This PR builds on #5459 and partially replaces #4945 (covering YAML).
It also makes further steps towards #5007