Implement a core sitemap registry #5004

mherwege · 2025-09-03T14:35:06Z

With this PR, a central sitemap registry is created. This registry has providers that offer sitemaps provide sitemaps from different providers. The current ones are DSL sitemaps and UI created sitemaps. The code for these has been refactored to implement such providers.

The reasons for doing this are:

Currently the UI created sitemaps are created as model sitemaps in core, residing in the org.openhab.core.model.sitemap, so org.openhab.core.ui depends on this model package.
Without a registry which is decoupled from the model, that same model depency would have to be included in a YAML sitemap provider.
With the current structure, it is impossible to show the file based sitemaps in the UI, as they are not converted to a common format. It is one way. The same would be true for converting these to YAML. It would have to be based on the sitemap representation in the model classes.

With the current structure, whatever we do when creating a new sitemap provider forces pulling the org.openhab.core.model.sitemap package directly or indirectly.
It therefore seems more appropriate to decouple the internal sitemap representation from the DSL model and xtext code generation.

See for the background: #4945 (comment) and #4945 (comment)

This PR prepares for:

Create a YAML sitemap provider.
Supporting a YAML format for sitemaps with the possibility to convert between them. See Sitemap DSL and YAML serialization #4945. This linked PR should be refactored to build on this one.
Refactor UI code to show (non-editable) representations of sitemaps provided from sitemap files or YAML files. This will require extra endpoints independent of the current once that only include configurations for UI managed sitemaps.
Do transparent conversions between the formats.

This PR is accompanied by the webui PR (openhab/openhab-webui#3349) that adapts the dependencies for BasicUI and CometVisu. Other UI's should not be concerned as they all work purely through the REST API and SSE events.

This is of course a major refactoring. Therefore there is a high risk and probability of some regressions and needs to be tested extensively. Code tests run through and my tests have not revealed issues so far. But I do expect there may be some.

@lolodomo I believe this is a better basis to continue work on YAML and DSL conversion afterwards.

Copilot

Pull Request Overview

This PR implements a core sitemap registry that decouples sitemap handling from the model packages. It creates a central registry for sitemaps with providers for different sources (DSL sitemaps and UI-created sitemaps) and introduces a new org.openhab.core.sitemap module with a factory-based approach for sitemap creation.

Creates a central SitemapRegistry to manage sitemaps from different providers
Introduces a new org.openhab.core.sitemap module with interfaces and implementations
Refactors existing UI sitemap provider to use the new registry architecture

Reviewed Changes

Copilot reviewed 91 out of 91 changed files in this pull request and generated 8 comments.

File	Description
Feature/Karaf configurations	Updates feature definitions to include new sitemap module and remove model dependencies
Test configurations	Adds sitemap module dependency to integration test bundles
UI module refactoring	Updates UI components to use new sitemap interfaces instead of model classes
New sitemap module	Introduces core sitemap interfaces, registry, factory, and implementations

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

Copilot · 2025-09-03T14:55:07Z

...rg.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/proxy/ProxyServletService.java

            try {
-                uri = createURIFromString(uriString);
+                uri = createURIFromString(uriString != null ? uriString : "");


Passing an empty string to createURIFromString when uriString is null may cause MalformedURLException or URISyntaxException. The original null check and early return should be preserved or handled appropriately.

I will change that. The problem was there before but would generate a null pointer exception, as the model classes are not annotated.

Copilot · 2025-09-03T14:55:07Z

...ore.ui/src/main/java/org/openhab/core/ui/internal/components/UIComponentSitemapProvider.java


    private static final Pattern CONDITION_PATTERN = Pattern
-            .compile("((?<item>[A-Za-z]\\w*)?\\s*(?<condition>==|!=|<=|>=|<|>))?\\s*(?<sign>\\+|-)?(?<state>.+)");
+            .compile("((?<item>[A-Za-z]\\w*)?\\s*(?<condition>==|!=|<=|>=|<|>))?\\s*(?<value>(\\+|-)?.+)");


The regex pattern change from separate 'sign' and 'state' groups to a single 'value' group may break existing condition parsing. The original pattern allowed for more structured parsing of conditions.

Suggested change

.compile("((?<item>[A-Za-z]\\w*)?\\s*(?<condition>==|!=|<=|>=|<|>))?\\s*(?<value>(\\+|-)?.+)");

.compile("((?<item>[A-Za-z]\\w*)?\\s*(?<condition>==|!=|<=|>=|<|>))?\\s*(?<sign>\\+|-)?(?<state>.+)");

The separate sign read into a separate field was only there to cope with a DSL parser limitation. The full value is needed, so no need to replicate these separate fields in the core representation of a condition value.

Copilot · 2025-09-03T14:55:08Z

...ore.ui/src/main/java/org/openhab/core/ui/internal/components/UIComponentSitemapProvider.java

+                        mapping.setCmd(cmd != null ? cmd : "");
                        mapping.setReleaseCmd(releaseCmd);
-                        mapping.setLabel(label);
+                        mapping.setLabel(label != null ? label : "");


Setting empty strings as default values for cmd and label may cause issues if the consuming code expects null values for missing/unset commands and labels.

This should be fine.

Copilot · 2025-09-03T14:55:08Z

...ore.ui/src/main/java/org/openhab/core/ui/internal/components/UIComponentSitemapProvider.java

+                        mapping.setCmd(cmd != null ? cmd : "");
                        mapping.setReleaseCmd(releaseCmd);
-                        mapping.setLabel(label);
+                        mapping.setLabel(label != null ? label : "");


Setting empty strings as default values for cmd and label may cause issues if the consuming code expects null values for missing/unset commands and labels.

This should be fine.

Copilot · 2025-09-03T14:55:08Z

...ore.ui/src/main/java/org/openhab/core/ui/internal/components/UIComponentSitemapProvider.java

+            if (sourceRules instanceof Collection<?> sourceRulesCollection) {
+                for (Object sourceRule : sourceRulesCollection) {
+                    if (sourceRule instanceof String) {
+                        String argument = !key.equals("visibility") ? getRuleArgument(sourceRule.toString()) : null;


[nitpick] The hardcoded string comparison with 'visibility' makes the code brittle. Consider using constants or an enum for rule types to improve maintainability.

I doubt it is worth externalizing just this string.

Copilot · 2025-09-03T14:55:08Z

...ore.sitemap/src/main/java/org/openhab/core/sitemap/internal/registry/SitemapFactoryImpl.java

+import org.osgi.service.component.annotations.Component;
+
+/**
+ * The {@link SitemapFactoryImpl} implements the {@link SitemapRegistry}


The class comment incorrectly states that SitemapFactoryImpl implements SitemapRegistry, but it actually implements SitemapFactory.

Suggested change

* The {@link SitemapFactoryImpl} implements the {@link SitemapRegistry}

* The {@link SitemapFactoryImpl} implements the {@link SitemapFactory}

Copilot · 2025-09-03T14:55:09Z

...les/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/internal/WidgetImpl.java

+
+    @Override
+    public String getWidgetType() {
+        return this.getClass().getInterfaces()[0].getSimpleName();


Accessing the first interface without checking if any interfaces exist can cause ArrayIndexOutOfBoundsException. This implementation assumes the widget always implements exactly one interface in a specific order.

Suggested change

return this.getClass().getInterfaces()[0].getSimpleName();

Class<?>[] interfaces = this.getClass().getInterfaces();

if (interfaces.length > 0) {

return interfaces[0].getSimpleName();

} else {

return this.getClass().getSimpleName();

}

Yes, it does assume it always implements the widget's interface and it is the first interface. I don't think these checks add much.

Copilot · 2025-09-03T14:55:09Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Widget.java

+     *
+     * @param visibility
+     */
+    void setVisibility(List<Rule> visibility);


Parameter name 'visiblity' should be 'visibility' to match the method name and consistent naming convention.

Suggested change

void setVisibility(List<Rule> visibility);

void setVisibility(List<Rule> visibility);

Already changed.

Parameter name could be visibilityRules

mherwege · 2025-09-04T07:13:17Z

There is a new package org.openhab.core.sitemap that has this sitemap registry code. org.openhab.core.ui still contains code that is only used for sitemaps (ItemUIRegistry, ChartProvider, ...). Should these be moved to this new package as well? Only UIComponentSitemapProvider would be left as long as managed sitemaps are stored in the UI component store.

Signed-off-by: Mark Herwege <[email protected]>

lolodomo · 2025-09-14T09:15:03Z

@mherwege : this message just to inform you that I am not ignoring your PR at all, I will review it.

lolodomo · 2025-09-20T09:56:00Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Buttongrid.java

+    List<ButtonDefinition> getButtons();
+
+    /**
+     * Replace the button grid buttons a new list of buttons.


Typo: "with" is missing

lolodomo · 2025-09-20T10:07:37Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Widget.java

+     *
+     * @return label color rules
+     */
+    List<Rule> getLabelColor();


Maybe rather getLabelColorRules and setLabelColorRules ?

Yes, that would be possible. But it would also mean the change in consuming classes is more then just changing the import. As much as possible, I kept the same method names from what they where before in the model, so I only had to change imports and do some cleanup. But now may be the right time to use more appropriate names as this is a major change anyway. @lolodomo What do you think? I left it as is for now.

lolodomo · 2025-09-20T10:08:14Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Widget.java

+     *
+     * @return value color rules
+     */
+    List<Rule> getValueColor();


Maybe rather getValueColorRules and setValueColorRules ?

lolodomo · 2025-09-20T10:09:13Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Widget.java

+     *
+     * @return icon color rules
+     */
+    List<Rule> getIconColor();


Maybe rather getIconColorRules and setIconColorRules ?

lolodomo · 2025-09-20T10:10:27Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Widget.java

+     *
+     * @return visibility rules
+     */
+    List<Rule> getVisibility();


Maybe rather getVisibilityRules and setVisibilityRules ?

lolodomo · 2025-09-20T10:12:53Z

bundles/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/Sitemap.java

+     * Returns the sitemap name.
+     *
+     * @return sitemap name.
+     * @see #setName(String)


All these @see in this interface looks like useless as they just reference them each other.

Ended there because they started as copies of the generated model classes, but will remove.

lolodomo · 2025-09-20T10:31:27Z

...les/org.openhab.core.sitemap/src/main/java/org/openhab/core/sitemap/internal/WidgetImpl.java

+    private List<Rule> labelColor = new CopyOnWriteArrayList<>();
+    private List<Rule> valueColor = new CopyOnWriteArrayList<>();
+    private List<Rule> iconColor = new CopyOnWriteArrayList<>();
+    private List<Rule> visibility = new CopyOnWriteArrayList<>();


I would suggest labelColorRules, valueColorRules, ... etc

lolodomo · 2025-09-20T10:41:28Z

...re.sitemap/src/main/java/org/openhab/core/sitemap/internal/registry/SitemapRegistryImpl.java

+
+    @Override
+    protected void notifyListenersAboutUpdatedElement(Sitemap oldElement, Sitemap element) {
+        registryChangeListeners.forEach(listener -> listener.updated(oldElement, element));


There is no notify method to call in super class ?

This could probably be much more simple. As I ended up extending AbstractRegistry, only the last 2 methods (addSitemapProver and removeSitemapProvider) are needed. AbstractRegistry keeps track of the listeners itself. I will make the change that way, but will need to do a full test.

lolodomo · 2025-09-20T10:49:40Z

I started by reviewing org.openhab.core.sitemap. The only question I have is if you did not forget that it is a possible to have a default rule condition to set a particular value when none of the other conditions are valid.
Regarding the default value of some attributes, I have not checked that the default is the same as before.

lolodomo · 2025-09-20T11:10:48Z

...ore.ui/src/main/java/org/openhab/core/ui/internal/components/UIComponentSitemapProvider.java

+                case Default defaultWidget:
+                    setWidgetPropertyFromComponentConfig(defaultWidget, component, "height");
+                    break;
+                default:


Looks like you forgot the case of Switch to call addWidgetMappings

Indeed, thank you.

lolodomo · 2025-09-20T11:27:20Z

...ore.ui/src/main/java/org/openhab/core/ui/internal/components/UIComponentSitemapProvider.java

+                        mapping.setCmd(cmd != null ? cmd : "");
                        mapping.setReleaseCmd(releaseCmd);
-                        mapping.setLabel(label);
+                        mapping.setLabel(label != null ? label : "");


For consistency, you could do the same as in addWidgetButtons, that is testing if value is not null before calling setCmd and setLabel.

lolodomo · 2025-09-20T12:23:49Z

...openhab.core.ui/src/test/java/org/openhab/core/ui/internal/items/ItemUIRegistryImplTest.java

    @Test
    public void getWidgetUnknownPageId() throws ItemNotFoundException {
-        Sitemap sitemap = SitemapFactory.eINSTANCE.createSitemap();
+        Sitemap sitemap = sitemapFactoryMock.createSitemap(SITEMAP_NAME);


Is it normal to not have any when(sitemapFactoryMock.createSitemap) ?

I don't understand your question here. I can't create a sitemap for testing anymore the same way as before when it was using the model. So I reverted to a mock.

lolodomo · 2025-09-20T13:20:34Z

...t.sitemap/src/main/java/org/openhab/core/io/rest/sitemap/internal/WidgetsChangeListener.java

        if (itemToBeSent != null) {
-            String widgetTypeName = widget.eClass().getInstanceTypeName()
-                    .substring(widget.eClass().getInstanceTypeName().lastIndexOf(".") + 1);
+            String widgetTypeName = widget.getClass().getSimpleName();


Rather widget.getWidgetType() ?

Missed this when creating the method in Widget.

mherwege · 2025-09-20T16:43:47Z

The only question I have is if you did not forget that it is a possible to have a default rule condition to set a particular value when none of the other conditions are valid.

The behaviour should not have changed. item and condition in a Condition are nullable, only value is not.

Signed-off-by: Mark Herwege <[email protected]>

mherwege requested a review from a team as a code owner September 3, 2025 14:35

mherwege mentioned this pull request Sep 3, 2025

Adapt UI's to core sitemap registry implementation openhab/openhab-webui#3349

Open

wborn requested a review from Copilot September 3, 2025 14:41

mherwege mentioned this pull request Sep 3, 2025

Sitemap DSL and YAML serialization #4945

Draft

Copilot AI reviewed Sep 3, 2025

View reviewed changes

mherwege mentioned this pull request Sep 4, 2025

Request for Feedback: Sitemap and other UI component definitions #5007

Open

jimtng mentioned this pull request Sep 4, 2025

Changes in core sitemap implementation openhab/openhab-jruby#487

Open

mherwege added 4 commits September 6, 2025 20:48

sitemap registry

4c39352

Signed-off-by: Mark Herwege <[email protected]>

fix javadoc

f48ac16

Signed-off-by: Mark Herwege <[email protected]>

fix javadoc

40a340a

Signed-off-by: Mark Herwege <[email protected]>

copilot review

af8145b

Signed-off-by: Mark Herwege <[email protected]>

mherwege force-pushed the sitemap_registry branch from aa5094a to af8145b Compare September 6, 2025 18:54

lolodomo reviewed Sep 20, 2025

View reviewed changes

mherwege added 2 commits September 20, 2025 19:00

review adjustments

f9bbe19

Signed-off-by: Mark Herwege <[email protected]>

fix javadoc

7c2a8c5

Signed-off-by: Mark Herwege <[email protected]>

	.compile("((?<item>[A-Za-z]\\w)?\\s(?<condition>==\|!=\|<=\|>=\|<\|>))?\\s*(?<value>(\\+\|-)?.+)");
	.compile("((?<item>[A-Za-z]\\w)?\\s(?<condition>==\|!=\|<=\|>=\|<\|>))?\\s*(?<sign>\\+\|-)?(?<state>.+)");

	* The {@link SitemapFactoryImpl} implements the {@link SitemapRegistry}
	* The {@link SitemapFactoryImpl} implements the {@link SitemapFactory}

-        return this.getClass().getInterfaces()[0].getSimpleName();
+        Class<?>[] interfaces = this.getClass().getInterfaces();
+        if (interfaces.length > 0) {
+            return interfaces[0].getSimpleName();
+        } else {
+            return this.getClass().getSimpleName();
+        }

	void setVisibility(List<Rule> visibility);
	void setVisibility(List<Rule> visibility);

Uh oh!

Implement a core sitemap registry #5004

Are you sure you want to change the base?

Implement a core sitemap registry #5004

Uh oh!

Conversation

mherwege commented Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull Request Overview

Reviewed Changes

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Sep 3, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mherwege commented Sep 4, 2025

Uh oh!

lolodomo commented Sep 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mherwege Sep 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mherwege commented Sep 3, 2025 •

edited

Loading

mherwege Sep 20, 2025 •

edited

Loading

lolodomo Sep 20, 2025 •

edited

Loading