Hey guys, I’ve been looking into the various issues with the basic UI for a couple days now :
And I know what the problem is, and I know various ways to fix it, but I’m not sure which one would be the right way to do it.
The problem(s) :
- ImageRenderer and VideoRenderer were never going to work.
This code (openhab-webui/bundles/org.openhab.ui.basic/src/main/java/org/openhab/ui/basic/internal/render/ImageRenderer.java at a038730ee58650639c1f8254a1263dc95ecd9402 · openhab/openhab-webui · GitHub) doesn’t resolve to anything that is present for UI generated sitemaps. The video renderer (openhab-webui/bundles/org.openhab.ui.basic/src/main/java/org/openhab/ui/basic/internal/render/VideoRenderer.java at a038730ee58650639c1f8254a1263dc95ecd9402 · openhab/openhab-webui · GitHub) is a bit worse since it doesn’t check, so this will actually crash entirely giving you a 500 error in any basic ui sitemap that has a video tag. That’s not good. - ProxyServlet has no idea about anything that wasn’t file loaded.
The proxy server which is references in the sitemaps receives parameters from the renderers of sitemap and widgetId. Problem is that proxy has no idea about the new UIComponent classes, so it’s just looking into the Model Repository which doesn’t have any references to the UI generated content. (openhab-core/bundles/org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/proxy/ProxyServletService.java at 49e148ad7dc13fd5935348055083b1bf6063e527 · openhab/openhab-core · GitHub).
The overall solution (generic) :
ImageRender and VideoRenderer can both be fixed by passing “sitemap” to them as a field(which has to be done in the PageRenderer) since there isn’t anyway that I can see that they can find their sitemap based just on the Widget. I’ve already done this here locally and it works fine and generates a valid “proxy address”. The proxy still needs to be fixed to actually display that content. To be able to do that, it’ll need to be made aware of the second Sitemap provider. This would probably mean that the proxy servlet would need to implement ModelRepositoryChangeListener so it can build up a list of providers.
Now on to the “I don’t know” :
Sorry for my getting into the game a little late here, but I don’t know the direction of all these things, so I’m not sure what is eventually “going away” and what should be the proper way to fix this. There are a ton of ways to make this right, though I’m not sure what is best here.
- Should the rest service just generate the sitemap file? Of course then you’d need to handle that all over the place that has been coded for the 2 providers. Same of the other way around if all sitemaps were to be loaded into the UIComponent set.
- Should we be using proxy, or are we now depending on nginx instance to do this for us? Is proxy still being supported moving forward?
- I get that what was done here was a good effort to handle both UI items and file based, though would it make sense to create an abstract wrapper that does all this work for us(finding items in both(or many) providers?
- Is using basic ui still a viable option going forward, or is the project leaning towards a different look for the UI with main UI and such. This has been broken and was reported quite some time ago and no one seems to care too much, so I’m wondering if I’m the only one?
Thanks your all your time, sorry this was so long.