-
-
Notifications
You must be signed in to change notification settings - Fork 429
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
Conversation
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. |
There was a problem hiding this 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 + "]"; |
There was a problem hiding this comment.
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()); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes
@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. |
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. |
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) . |
@mherwege : can you prepare a small PR for Basic UI without changing everything but just fixing the issue introduced by this PR? |
Just for my understanding: I think it would be nice to have the item unit as a dedicated field in the normal item response, too ... |
Your BasicUI PR is fine and ready to be merged. 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. |
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. |
PR is here openhab/openhab-webui#1923. |
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. |
Basic UI uses code in |
It uses exactly the same code to get the unitSymbol in
Do we have a stronger guarantee that |
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]>
Basic UI is now ready for this change (PR is merged). |
@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). |
There was a problem hiding this 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 : ""); | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
remove empty line
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
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]>
Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
Signed-off-by: Mark Herwege <[email protected]>
@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]>
@J-N-K : any chance to merge this PR before new milestone is generated ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks.
Fix openhab/openhab-webui#1951 Signed-off-by: Laurent Garnier <[email protected]>
Fix openhab/openhab-webui#1951 Signed-off-by: Laurent Garnier <[email protected]>
…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
Fix openhab/openhab-webui#1951 Signed-off-by: Laurent Garnier <[email protected]> GitOrigin-RevId: b2934ad
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]>
Fix openhab/openhab-webui#1953 Fix a regression introduced by PR openhab#3644 Signed-off-by: Laurent Garnier <[email protected]>
…3708) Fix openhab/openhab-webui#1953 Fix a regression introduced by PR #3644 Signed-off-by: Laurent Garnier <[email protected]>
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:
getFormatPattern
listed aboveIn 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.