Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[rest] Add widget state pattern and default unit to ItemUIRegistry #3644

Merged
merged 7 commits into from
Jul 2, 2023

Conversation

mherwege
Copy link
Contributor

@mherwege mherwege commented Jun 5, 2023

Resolves #3624

When developing the Input widget type for BasicUI and the Android app, I ran into a number of constraints to properly support an input widget in all cases. Having better access to the defined pattern and default unit would make this a lot simpler for BasicUI (using the methods of ItemUIRegistry) and make things possible that are not possible at this time in the Android app.

The fundamental problem is that format patterns are meant to be used for visualisation, but not as an input mask. Still, also in the input widget, one wants to use the formatted value (otherwise, you end up with the wrong unit, or digits beyond what is needed). Also, if a value is undefined, it would still be required to show the unit from the state pattern if available (or the default unit if not).

This PR proposes to extend ItemUIRegistry methods by providing a getFormatPattern method. This method will get the format pattern from the widget label, resp. item label, resp. item state description.

The sitemap REST response has following additional fields:

  • pattern: widget format pattern (using the value from the getFormatPattern listed above
  • unit: unit of the widget, also available when the value is NULL or UNDEF

In addition, the item REST part of the sitemap response contains an extra field, unitSymbol with the default unit or defined unit from meta data, so this can be shown for NULL or UNDEF value if no format or no state description is provided.

All existing tests for ItemUIRegistry run through fine. A modified version of BasicUI is also a lot simpler with these changes added and has been tested to work. I will amend openhab/openhab-webui#1787 and push a version making use of the functionality in this PR if this PR would be accepted.

While this will simplify things in the UI's, this is not an absolute must for BasicUI. For the Android app, a user would need to make sure to provide a simplified format in the label to be able to use the input field consistently. This PR would allow to work around this. It does provide all info in the REST API to avoid ambiguity.

@mherwege mherwege requested a review from a team as a code owner June 5, 2023 16:06
@lolodomo
Copy link
Contributor

lolodomo commented Jun 9, 2023

All my OH free time is currently focussed on implementing the mew semantic tag registry but I hope I can review that PR during the weekend.

Copy link
Contributor

@lolodomo lolodomo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that you are updating a very sensible (and complex) part.
I hope this will break nothing.

Note also that your change in convertState will break the slider widget in Basic UI as Basic UI does not expect a unit in that case. A fix in Basic UI should be prepared.

label = label.substring(0, label.indexOf("[") + 1) + formatPattern + "]";
int index = label.indexOf("[");
if (index >= 0) {
label = label.substring(0, label.indexOf("[") + 1) + formatPattern + "]";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use index

}

} catch (ItemNotFoundException e) {
logger.error("Cannot retrieve item '{}' for widget {}", itemName, w.eClass().getInstanceTypeName());
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a too much high log level. WARN level should be sufficient.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This wasn't consistent across the class and I just copied one with error level. I will make it warn everywhere.

@@ -93,6 +94,10 @@ private static EnrichedItemDTO map(Item item, ItemDTO itemDTO, boolean drillDown

EnrichedItemDTO enrichedItemDTO;

String unitSymbol = null;
if (item instanceof NumberItem numberItem) {
unitSymbol = numberItem.getUnitSymbol();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the item internal unit ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

@lolodomo
Copy link
Contributor

@J-N-K or @kaikreuzer : as this PR is updating a very sensible part of sitemap UIs, please do an attentive review. I have the feeling it is OK. Please also check the pattern strings, I am not very familiar with their syntax.

As already mentioned, the change at line 694 will break slider in Basic UI for numbers with dimension. So a fix must be prepared for Basic UI and merges should be consecutive.

@mherwege
Copy link
Contributor Author

As already mentioned, the change at line 694 will break slider in Basic UI for numbers with dimension. So a fix must be prepared for Basic UI and merges should be consecutive.

I will look into this. The change in line 694 is based on @J-N-K suggestion here: #3624 (comment). Keen to know if there are other consequences. This case is not covered by unit tests.

@lolodomo
Copy link
Contributor

lolodomo commented Jun 12, 2023

In file smarthome.js (BasicUI), line 1698 has to be fixed and comment at line 1683 has to be removed. Line 1659 has to be checked too (I am not sure of the behaviour of parseInt) .
Setpoint widget is properly handled, so code can be looked at line 973.

@lolodomo
Copy link
Contributor

lolodomo commented Jun 12, 2023

@mherwege : can you prepare a small PR for Basic UI without changing everything but just fixing the issue introduced by this PR?

@mherwege
Copy link
Contributor Author

@lolodomo I create the PR , but have one outstanding question on there.

@spacemanspiff2007
Copy link
Contributor

Just for my understanding:
When I asked to include the metadata in the item events it was always rejected because it might be not available when the event is issued (or some implementation using a custom metadata provider).
How is this reflected with in this PR? Will the item unit then be wrongly not set?

I think it would be nice to have the item unit as a dedicated field in the normal item response, too ...

@lolodomo
Copy link
Contributor

lolodomo commented Jun 13, 2023

@lolodomo I create the PR , but have one outstanding question on there.

Your BasicUI PR is fine and ready to be merged.
So we are now waiting for core maintainers review of the current PR.

I believe there is a good chance of fast merge so you can start adjusting your PR for new input widget (BasicUI).

@lolodomo
Copy link
Contributor

I believe there is a good chance of fast merge so you can start adjusting your PR for new input widget (BasicUI).

Maybe create a separate PR in case this PR is not merged fast.
In any case, my intention is to merge your Basic UI stuff related to input widget whatever the solution, before OH4 is released.

@lolodomo
Copy link
Contributor

To avoid a new infinite debate about unit management in OH, I would suggest to cut this PR in two, one for REST item (to be debated) , and one for REST sitemap. Idea is to not delay the REST sitemap part which is waited.

@mherwege
Copy link
Contributor Author

Maybe create a separate PR in case this PR is not merged fast.
In any case, my intention is to merge your Basic UI stuff related to input widget whatever the solution, before OH4 is released.

PR is here openhab/openhab-webui#1923.

@mherwege
Copy link
Contributor Author

To avoid a new infinite debate about unit management in OH, I would suggest to cut this PR in two, one for REST item (to be debated) , and one for REST sitemap. Idea is to not delay the REST sitemap part which is waited.

I removed the changes to the item REST part and will do that in a separate PR. However, I am not sure this is solving the potential problem. The unit is retrieved in ItemUIRegistryImpl, and the changes there are necessary for supporting BasicUI. If it is available there, it will be in the REST api, or am I missing something? If it is not available, it will also not work in BasicUI.

@lolodomo
Copy link
Contributor

However, I am not sure this is solving the potential problem. The unit is retrieved in ItemUIRegistryImpl, and the changes there are necessary for supporting BasicUI. If it is available there, it will be in the REST api, or am I missing something? If it is not available, it will also not work in BasicUI.

Basic UI uses code in ItemUIRegistryImpl + REST sitemap API but does not rely on REST item API.

@mherwege
Copy link
Contributor Author

Basic UI uses code in ItemUIRegistryImpl + REST sitemap API but does not rely on REST item API.

It uses exactly the same code to get the unitSymbol in ItemUIRegistryImpl and the proposed change to the REST item API:

        if (item instanceof NumberItem numberItem) {
            unitSymbol = numberItem.getUnitSymbol();
        }

Do we have a stronger guarantee that getUnitSymbol returns the unit from the unit metadata when called from ItemUIRegistryImpl, and not the default unit if the metadata is not available yet? I don't know. If that's not the case, I don't see a difference. And it suggests that overriding the default unit should actually not be stored in the metadata, but should be a field in NumberItem to avoid this kind of situation. But that's far beyond the scope of this PR, and is independent of it.

lolodomo pushed a commit to openhab/openhab-webui that referenced this pull request Jun 14, 2023
Adjust BasicUI slider unit handling.
So far, the unit was not passed on to the slider. With proposed changes
in core openhab/openhab-core#3644, unit would be
passed and needs to stripped for the slider to work properly.

Signed-off-by: Mark Herwege <[email protected]>
@lolodomo
Copy link
Contributor

Basic UI is now ready for this change (PR is merged).

@lolodomo
Copy link
Contributor

@openhab/core-maintainers : please tell us if there is an intention or not to review & merge this PR before OH4 is released. I need this answer to review & merge the right Basic UI PR from @mherwege (input field).

Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise LGTM, even though iterating over the regex seems to be expensive.

@lolodomo Did you try if that works?

}
pattern = pattern.substring(0, matcherEnd) + (!unit.isBlank() ? " " + unit : "");
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove empty line

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@lolodomo
Copy link
Contributor

lolodomo commented Jun 18, 2023

@lolodomo Did you try if that works?

No, I did not try it myself.
But I hope @mherwege did try it.

@mherwege
Copy link
Contributor Author

But I hope @mherwege did try it.

Yes, I did try.

Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
@mherwege
Copy link
Contributor Author

mherwege commented Jun 19, 2023

@J-N-K I removed the regex iteration. As this check is only done for number items, there should only be one % format string, so I can just take the first one and declare invalid what comes after. I tested with various patterns (valid and invalid) and it still does what I expect it to do.

Signed-off-by: Mark Herwege <[email protected]>
@lolodomo
Copy link
Contributor

lolodomo commented Jul 2, 2023

@J-N-K : any chance to merge this PR before new milestone is generated ?

Copy link
Member

@J-N-K J-N-K left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks.

@J-N-K J-N-K added enhancement An enhancement or new feature of the Core REST/SSE labels Jul 2, 2023
@J-N-K J-N-K changed the title Add widget state pattern and default unit to ItemUIRegistry interface and REST API response [rest] Add widget state pattern and default unit to ItemUIRegistry Jul 2, 2023
@J-N-K J-N-K merged commit 5ceaa64 into openhab:main Jul 2, 2023
lolodomo added a commit to lolodomo/openhab-core that referenced this pull request Jul 5, 2023
J-N-K pushed a commit that referenced this pull request Jul 5, 2023
splatch pushed a commit to ConnectorIO/copybara-hab-core that referenced this pull request Jul 12, 2023
…penhab#3644)

* expose widget format pattern to sitemap REST
* Add unit fields to sitemap REST

Signed-off-by: Mark Herwege <[email protected]>
GitOrigin-RevId: 5ceaa64
splatch pushed a commit to ConnectorIO/copybara-hab-core that referenced this pull request Jul 12, 2023
lolodomo pushed a commit to openhab/openhab-webui that referenced this pull request Jul 14, 2023
This PR is a continuation of
#1787, using the extra
functionality provided by core if
openhab/openhab-core#3644 gets merged in core.
It would be an alternative to
#1787 with the same
functionality, but reduced complexity.

Requires openhab/openhab-core#3644.

---------

Signed-off-by: Mark Herwege <[email protected]>
@wborn wborn added this to the 4.0 milestone Jul 15, 2023
lolodomo added a commit to lolodomo/openhab-core that referenced this pull request Jul 17, 2023
J-N-K pushed a commit that referenced this pull request Jul 17, 2023
@mherwege mherwege deleted the ui_pattern branch July 28, 2023 10:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement An enhancement or new feature of the Core REST/SSE
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[REST API] Add widget state format to sitemap response
5 participants