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.

Except if I miss something, that looks very easy to change and with no particular difficulty in both sitemap providers.

It is not about the sitemap providers. It is about the UI's, where this change would have to be applied as well.

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.

As sitemapFactoryMock is a mock, I don't understand what can be the result of calling sitemapFactoryMock.createSitemap if you don't define something like when(sitemapFactoryMock.createSitemap)

Fixed, looks like sitemap wasn't on the execution path, but I adjusted it anyway.

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]>

lolodomo · 2025-11-30T10:01:33Z

...org.openhab.core.ui/src/main/java/org/openhab/core/ui/internal/items/ItemUIRegistryImpl.java

    @Override
    public @Nullable String getConditionalIcon(Widget w) {
-        List<IconRule> ruleList = w.getIconRules();
+        List<Rule> rulList = w.getIconRules();


Please fix typo => ruleList

lolodomo · 2025-11-30T10:32:12Z

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

+    protected @Nullable Widget buildWidget(UIComponent component, Parent parent) {
+        Widget widget = sitemapFactory.createWidget(component.getType(), parent);

        if (widget != null) {


You could keep the existing warning "Unknown sitemap component type" in case widget is null

lolodomo · 2025-11-30T10:43:07Z

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

+            Class<?> clazz = widget.getClass();
+            Method method = List.of(clazz.getMethods()).stream().filter(m -> m.getName().equals(setterName)).findFirst()
+                    .get();
+            Class<?> argumentType = (method.getParameters()[0].getType());


You can remove unnecessary parenthesis

lolodomo · 2025-11-30T18:37:47Z

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

+                        Rule rule = sitemapFactory.createRule();
+                        List<Condition> conditions = getConditions(conditionsString, component, key);
+                        rule.setConditions(conditions);
+                        rules.add(rule);


I believe you forgot to call rule.setArgument when key is not "visibility".

lolodomo · 2025-11-30T19:21:39Z

bundles/org.openhab.core.model.sitemap/src/org/openhab/core/model/sitemap/Sitemap.xtext

-    ('visibility=[' (Visibility+=VisibilityRule (',' Visibility+=VisibilityRule)*) ']')?);
-
-ButtonDefinition:
+ModelFrame:


What is the need to prefix everything with "Model" ?

The new registry now has all of these classes without Model in front. If I would have kept the class names here, I would have ended up having to fully qualify in the methods I need both. I wanted to avoid that to keep the code cleaner and have a clear distinction. It will also avoid errors in external code as it should be clear the registry classes should be used rather than the model classes (it will not compile when it is not changed).

Oh yes I understand your point now.
Resolved.

lolodomo · 2025-11-30T19:22:49Z

bundles/org.openhab.core.model.sitemap/src/org/openhab/core/model/sitemap/Sitemap.xtext

+    {ModelFrame} 'Frame' (('item=' item=ItemRef) | ('label=' label=(ID | STRING)) |
+    ('icon=' icon=Icon) | ('icon=' IconRules=ModelIconRuleList) | ('staticIcon=' staticIcon=Icon) |
+    ('labelcolor=' labelColor=ModelColorArrayList) |
+    ('valuecolor=' valueColor=ModelColorArrayList) |
+    ('iconcolor=' iconColor=ModelColorArrayList) |
+    ('visibility=' visibility=ModelVisibilityRuleList))*;


Why did you replace many "&" by "|" ?

The & operator used like before leads to a Too Many Class Methods error. The issue is that xtext will create Java methods for each possible permutation in all possible sequences. This number of methods becomes huge very quickly. As I introduced the various List classes for the rules, I ran into the limit of > 65535 methods on the generated Java class. Adding syntactical elements at any point in time would probably have gotten us at the limit as well.

That's also the reason why I added extra checks for item and icon in the validator, as this is no longer enforced by the syntax.

The alternative approach would have been to fix the sequence of the attributes in the grammar, but that would have been a breaking change in the syntax.

lolodomo · 2025-11-30T20:10:42Z

...nhab.core.model.sitemap/src/org/openhab/core/model/sitemap/internal/SitemapProviderImpl.java

+                Rule colorRule = sitemapFactory.createRule();
+                addRuleConditions(colorRule.getConditions(), modelColorRule.getConditions());


Call to colorRule.setArgument is missing

lolodomo · 2025-11-30T20:24:53Z

...nhab.core.model.sitemap/src/org/openhab/core/model/sitemap/internal/SitemapProviderImpl.java

+            case EventType.MODIFIED:
+                if (sitemap != null && oldSitemap != null) {
+                    notifyListenersAboutUpdatedElement(oldSitemap, sitemap);
+                }
+                break;


Don't know if you have to consider the case where oldSitemap is null and then calling notifyListenersAboutAddedElement

From what I could see, ADDED is being called (and should be called) when oldSitemap is null. The check in the MODIFIED case is just there to satisfy null annotations.

Ok.
Resolved

lolodomo · 2025-11-30T20:28:53Z

...nhab.core.model.sitemap/src/org/openhab/core/model/sitemap/internal/SitemapProviderImpl.java

+        getAll().forEach(sitemap -> {
+            notifyListenersAboutAddedElement(sitemap);
+        });


Sure that it is necessary ?

Wouldn't that be needed if the sitemap model bundle gets started after the sitemap registry bundle? I need to check, put a breakpoint in this method to see if it gets called. But it may be difficult as testing in Eclipse may have a different sequence than in real live.
In the worst case, it is never called. Does it harm?

lolodomo · 2025-11-30T20:45:05Z

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

-            boolean itemBelongsToWidget = w.getItem() != null && w.getItem().equals(item.getName());
+            boolean itemBelongsToWidget = w.getItem() != null && item.getName().equals(w.getItem());


Why did you reverse the equals ?
At least we are sure that w.getItem() is not null.

item.getName() is now correctly annotated as NonNull in the registry. Eclipse still gives me a warning for w.getItem() potentially null if you put it first. In theory, it could be, as you call w.getItem() twice and you should assign it to a local variable instead to avoid this.

I could actually drop the w.getItem() != null check completely now.

lolodomo · 2025-11-30T20:48:20Z

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

            if (!skipWidget && w instanceof Chart chartWidget) {
-                skipWidget = chartWidget.getRefresh() > 0;
+                Integer refresh = chartWidget.getRefresh();
+                skipWidget = refresh != null && refresh > 0;


chartWidget.getRefresh() returns an int so previous code was good and there is nothing to change.

Yes, indeed. I alternated between making it an Integer or not when developing I believe, but sticked with int in the end.

lolodomo · 2025-11-30T20:54:27Z

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

        // event.item contains the (potentially changed) data of the item belonging to
        // the widget including its state (in event.item.state)
-        boolean itemBelongsToWidget = widget.getItem() != null && widget.getItem().equals(item.getName());
+        boolean itemBelongsToWidget = widget.getItem() != null && item.getName().equals(widget.getItem());


See above, inverting avoid a null pointer warning in Eclipse.

lolodomo · 2025-11-30T21:15:52Z

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

-        bean.staticIcon = widget.getStaticIcon() != null || !widget.getIconRules().isEmpty();
+        bean.staticIcon = widget.isStaticIcon() || !widget.getIconRules().isEmpty();


bean.staticIcon = (widget.getIcon() != null && widget.isStaticIcon()) || !widget.getIconRules().isEmpty();

I am not sure this is necessary.

lolodomo · 2025-11-30T21:43:18Z

I just finished a full review.

lolodomo · 2025-12-01T08:08:35Z

I am asking myself about the risk to merge that change for 5.1, considering there is not a lot of time before the release. Maybe better to do it just after 5.1 is released?
I also started to review the required UI PR.

mherwege · 2025-12-01T09:53:39Z

I am asking myself about the risk to merge that change for 5.1, considering there is not a lot of time before the release. Maybe better to do it just after 5.1 is released?
I also started to review the required UI PR.

I was asking myself the same thing, and I agree. I also think that would give me the time to pick up working on the YAML side again and make it all available in OH5.2.

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

mherwege · 2025-12-01T11:05:20Z

@lolodomo Thank you very much for your extensive review. I made review adjustments and left a few comments.
I notice there are a few conflicts, but I will refrain from rebasing until we are through the review.

lolodomo · 2025-12-01T18:28:13Z

I realise that one file (sitemap validation checks) remains to be reviewed.

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

mherwege · 2026-01-05T08:32:03Z

@lolodomo Should I rebase this now we are working towards OH 5.2, or do you want me to wait? How do you want to proceed?
I very much won't to not let this to the last moment before a release. This is too risky.

lolodomo · 2026-01-05T19:25:54Z

Let me finish the review first, it was done at around 98% (just one file still to be reviewed), I also need to check your last changes.
Then I will have to review your corresponding UI PR (already started) as they will have to be merged together.
Your stuff is my review priority 2, the first being YAML rule file provider by @Nadahar (who is waiting since more time than you).
My intention, even if I am not the one who can decide & merge, would be to have both YAML rule file provider and new sitemap core registry in first milestone of 5.2.
Then you can continue the work with sitemap (YAML, integration to create and parse APIs, changes in Main UI) during 5.2 development.

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]>

lolodomo reviewed Nov 30, 2025

View reviewed changes

review feedback

28dc866

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

simplify checks

a1608a1

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);

		Rule colorRule = sitemapFactory.createRule();
		addRuleConditions(colorRule.getConditions(), modelColorRule.getConditions());

		boolean itemBelongsToWidget = w.getItem() != null && w.getItem().equals(item.getName());
		boolean itemBelongsToWidget = w.getItem() != null && item.getName().equals(w.getItem());

		bean.staticIcon = widget.getStaticIcon() != null \|\| !widget.getIconRules().isEmpty();
		bean.staticIcon = widget.isStaticIcon() \|\| !widget.getIconRules().isEmpty();

Uh oh!

Implement a core sitemap registry #5004

Are you sure you want to change the base?

Implement a core sitemap registry #5004

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!

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

mherwege commented Sep 3, 2025 •

edited

Loading

mherwege Sep 20, 2025 •

edited

Loading

lolodomo Sep 20, 2025 •

edited

Loading