Yeah, the problem is that widgets are already YAML. They just describe a different structure than what “the new YAML format” does. The current widgets describe the actual object structure (directly translated from JSON), while “the new YAML format” is something undefined, where structure is altered so that (some) people think the structure is easier to handle. Thus, it’s not really possible to make “new YAML” anything without long discussions about what these “alternative structures” should be.
That would be an easy solution, but I’m guessing that some people will want to turn everything that can possibly be changed from arrays to maps/objects, into maps/objects.
Keeping the “inner structure” the same would make it very easy to “convert” widgets, so I would definitely prefer that. Also, all the “turning arrays into maps” we do, must be undone again before the UI can actually use the widgets.
I’m confused. Of course it works, the “old YAML format” for rules and rule templates worked as well. It’s not about that, it’s about the idea that “using maps is more user-friendly”.
We had a working YAML system for rules and rule templates. The reason it had to be done “all over again” was to make it fit into “the spirit” of “the new YAML format”. The primary change was to turn arrays into maps where possible, in addition to shortening some terms (like config instead of configuration).
What I’m saying is that I expect that it will be demanded that a similar “transformation” takes place for pages and widgets. I would have preferred if the YAML reflected the actual structure of the data, the way the “old YAML” did, but that wasn’t the consensus. So, I assume that the same applies here.
At the moment, I’ve got a draft PR implementing it as I described
literal copy paste from existing widget yaml
add 2 extra indentation levels
convert uid to become the key under widgets section.
I don’t see any possible reason for converting any other “transformations” from arrays to maps to complicate this - but we’ll see how it goes. This probably won’t make it into 5.2 anyway, even though I live in hope.
OK that’s why I was confused. Let’s not continue with the speculation. It serves no productive purposes here, unless you are actually asking for this change, in which case feel free to do so in the PR review.
Every time I look at a home assistant youtube it just seems to be a big mess of yaml code. Every change they do you have to check the syntax and then restart home assistant as far as I could tell.
I haven’t really used home assistant but just by the videos is enough reason not to use it. It may have lots more support etc than openHab but I will stick with openHab. I don’t use the file options and ditched those in openHab 3 and also ditched DSL. I just use the UI and javascript.
I am not doing anything fancy so my system is fairly simple.
In my opinion, YAML is a terrible format, like all whitespace based formats. But, it has one good thing going for it, and that is the multiline strings. That makes it possible to embed scripts that are still readable. Except for that, not a lot of good to say about it from me.
That said, OH’s YAML format is versioned, so the idea is that it files won’t “break”. If breaking changes are done to the format, the version is bumped, which means that those using the old version will keep working as they did. That should avoid some of “the nightmare”.
I’ve adjusted the MainUI PR so that the YAML from the Code tab in the MainUI can be copy pasted into a file-based yaml and you’d only need to adjust the indentation level.
We can go one step further and make it the same as things/items: the code tab shows a full file syntax including version: 1, pages: - but I think I’ll leave that for a future PR since that’s another can of worms.
This is because the syntax for the widget is exactly the same. When there is a new version of the widget on the marketplace, simply redownload / overwrite the widget file. The addon will automatically reload the yaml file too!
I considered also supporting remote inclusion (with local caching) in the addon, but not quite sure if it’s a good idea. In any case that’s a separate topic.
It’s a bit unpractical to have “version++” (and indentation) inserted when working with them, extra indentations makes YAML much harder to work with in the UI editor too. I think that a better option might be a button with “Export to YAML” (or whatever), and when you click that button, you get the “extras” included. So, if you just want to work with it, you work with it without the extras, if you want to store it to a file, you use the button.
