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

Thing "actions" config param handling made generic #1498

Merged
merged 2 commits into from
Oct 8, 2022

Conversation

mbronk
Copy link
Contributor

@mbronk mbronk commented Sep 20, 2022

For Main UI's Thing-Details view.
Fixes #1491

Signed-off-by: Mateusz Bronk bronk.m+gh@gmail.com

@relativeci
Copy link

relativeci bot commented Sep 24, 2022

Job #547: Bundle Size — 11.33MB (~+0.01%).

7ed1c20(current) vs 2461bf7 main#546(baseline)

Metrics (2 changes)
                 Current
Job #547
     Baseline
Job #546
Initial JS 1.7MB(+0.05%) 1.7MB
Initial CSS 607.98KB 607.98KB
Cache Invalidation 17.86% 41.68%
Chunks 218 218
Assets 242 242
Modules 2007 2007
Duplicate Modules 110 110
Duplicate Code 1.82% 1.82%
Packages 133 133
Duplicate Packages 15 15
Total size by type (1 change)
                 Current
Job #547
     Baseline
Job #546
CSS 856.02KB 856.02KB
Fonts 1.08MB 1.08MB
HTML 1.19KB 1.19KB
IMG 140.74KB 140.74KB
JS 8.99MB (~+0.01%) 8.99MB
Media 295.6KB 295.6KB
Other 846B 846B

View job #547 reportView main branch activity

@mbronk mbronk force-pushed the private/mbronk/FR_1491 branch from 1d1a90d to c32ee3b Compare September 24, 2022 18:36
Copy link
Member

@ghys ghys left a comment

Choose a reason for hiding this comment

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

Thanks for the implementation, some remarks (and further discussion) below!

this.zwaveActions = this.configDescriptions.parameters.filter((p) => p.groupName === 'actions')
this.configDescriptions.parameters = this.configDescriptions.parameters.filter((p) => p.groupName !== 'actions')
// special treatment for actions (heuristic match by group name/label)
if (this.configDescriptions.parameterGroups.filter((pg) => pg.name === 'actions').every((pg) => pg.label === 'Actions' && pg.description === 'Actions')) {
Copy link
Member

Choose a reason for hiding this comment

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

This heuristic is good enough but since parameter groups have a "context" attribute:

https://next.openhab.org/javadoc/latest/org/openhab/core/config/core/dto/configdescriptionparametergroupdto

I'm wondering whether this could perhaps be the way to go - look for e.g. an "actions" context in the parameter group definition instead of checking for labels & descriptions - it certainly would be more elegant IMO.

We could still make an exception for the Z-Wave things unless @cdjackson agrees to add the "actions" context for the actions parameter group for them.

I'm not sure how easy that is to add such contexts to parameter groups, whether in declarative or imperative form.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Indeed, there seems to be a "param group context" defined, though not documented too widely. Per this it would seem it may be a freeform string (the per-param context seems to be a pre-defined list).
Let me try to see how easy it is to set/use and report back (may take me about a week to do so, though)...

I 100% agree it would be more elegant than this heuristic.
That said, I think the ROI is there when ZWave binding also adopts it, otherwise we're back into heuristic-land :). Not sure what'd be the timeline, but how about a 2-step approach? I.e. this heuristic for now (possibly with an "or" for a by-context match) and follow through with a proper update if/once ZWave binding changes?

Copy link
Member

Choose a reason for hiding this comment

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

I.e. this heuristic for now (possibly with an "or" for a by-context match) and follow through with a proper update if/once ZWave binding changes?

Works for me!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The "by-context" method does work indeed, so I added it as primary.
Any param group constructed with .withContext("actions") will now be picked as action container.

As per our discussion, I've left the heuristic match by name and label for compat with today's Z-wave binding.
Note I had to pull the "by description" criterion, since Z-Wave doesn't use it uniformly and only sets it on non-controller devices...

--
While at it, I attempted to make it a bit more generic (hopefully the code explains the intent well enough). Do ask if it raises any concerns.

let thing = this.thing
let save = this.save
if (action.type !== 'BOOLEAN') return
this.$f7.dialog.confirm(
`${action.label}?`,
`${action.description ?? action.label}?${action.verify ? '<p><small><strong class="text-color-yellow">WARNING:</strong>&nbsp;This action may be dangerous!</small></p>' : ''}`,
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
`${action.description ?? action.label}?${action.verify ? '<p><small><strong class="text-color-yellow">WARNING:</strong>&nbsp;This action may be dangerous!</small></p>' : ''}`,
`${action.description ?? action.label} ? ${action.verify ? '<p><small><strong class="text-color-yellow">WARNING:</strong>&nbsp;This action may be dangerous!</small></p>' : ''}`,

I'm not sure I understand this...

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 is a (rather naive indeed) attempt to bring back some of the semantics that verify has.
Ref:

verify | Specifies that this is parameter requires a verification stage with the user before sending.
       |  Parameters flagged with *verify=true* could be considered dangerous and should be protected
       | from accidental use by a UI - e.g. by adding an "Are you sure" prompt (optional).

The "actions" behaviour of Main UI does ask for a confirmation for all the actions, of course... so I figured to bring back at least some of the "verify" semantics, and add a notion of "hey, the binding developer considered this dangerous".
I am the first to agree this may be way too naive for a prompt, but would say... we should retain some of this semantics, otherwise all actions get "level" which is not the case (prime example is zwave: enabling inclusion mode (safe) and hard controller reset (destructive) ... yield the same kind of confirmation)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh. and the abovementioned code was not a ternary IF statement! It is just a good old questionmark (to be rendered as-is in the output :) ).

Copy link
Member

Choose a reason for hiding this comment

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

The "actions" behaviour of Main UI does ask for a confirmation for all the actions, of course... so I figured to bring back at least some of the "verify" semantics, and add a notion of "hey, the binding developer considered this dangerous".

Wow I completely forgot this "verify" attribute existed... 🤯

Fully agree with your assessment - this particular line of code I considered quite "convoluted" though with the muliple ternary expressions. If I understand it right it does display the description or label, or when there's none, displays a warning message if the verify flag is true? Is that your intent?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

or when there's none....

As per my 2nd comment... the ? here is not a ternary expresssion, actually, rather the same questionmark that existed in the original. The intent is to:

  1. Display description (and fallback to label if none)
  2. (orthogonal to the above): If verify==true --> add an extra warning.

I now see how poorly it reads code-wise (it was much better in IDE, with coloring, etc.). Unfortunately, I have literally never written anything in vue, so while I assume using some templated text/conditional controls would make it more readable, it would take me some extra learning to find the syntax out. Do you happen to have any tips in particular?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Extracted to separate variables - hope it'll be more readable now.

@mbronk mbronk force-pushed the private/mbronk/FR_1491 branch 3 times, most recently from d75fd7c to 97ecf63 Compare October 1, 2022 15:16
@ghys
Copy link
Member

ghys commented Oct 5, 2022

@mbronk Please review the ESLint errors: https://github.com/openhab/openhab-webui/actions/runs/3165087894/jobs/5209020387
(you can also see some in the Files tab but there's a limit on how many can be displayed per file, so some are missing towards the end of the file in that view).

If you can, use an editor that can highlight ESLint errors, for instance VS Code with the ESLint plugin - it's easier!

@mbronk mbronk force-pushed the private/mbronk/FR_1491 branch from 97ecf63 to 041add1 Compare October 7, 2022 19:21
@mbronk
Copy link
Contributor Author

mbronk commented Oct 7, 2022

@ghys Yeah, sorry about that!
I don't have any git hooks set up for this repo, and completely forgot to run npm run lint manually before pushing... Since the CI only runs after manually approved for 1st time committers... I then have forgotten about it :/

Anyways, eslint should be happy now. Could you please approve another CI build?

EDIT: Argh.. missclicked and updated this branch w/ merge vs. rebase. Let me fix that in just a sec. [DONE]

For Main UI's Thing-Details view.
Matching is by group param context ("actions") first, then falls back to
"by name" for Z-Wave binding backwards-compatibility.
Fixes openhab#1491

Signed-off-by: Mateusz Bronk <bronk.m+gh@gmail.com>
@mbronk mbronk force-pushed the private/mbronk/FR_1491 branch from 4c7d17a to 354ac11 Compare October 7, 2022 19:36
Signed-off-by: Yannick Schaus <github@schaus.net>
Copy link
Member

@ghys ghys left a comment

Choose a reason for hiding this comment

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

Thanks - LGTM!
I just removed the tooltip with the description on the action buttons because it didn't look too good on mobile IMO, especially with potentially long descriptions. You have that description on the confirmation dialog anyway so it's probably enough...?
Nice new feature!

(build failures were temporary, the build actually succeeded: checks/webpack-stats are green)

@ghys ghys merged commit 9246175 into openhab:main Oct 8, 2022
@ghys ghys added enhancement New feature or request main ui Main UI labels Oct 8, 2022
@ghys ghys added this to the 3.4 milestone Oct 8, 2022
@mbronk mbronk deleted the private/mbronk/FR_1491 branch October 9, 2022 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request main ui Main UI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[thing-details] Extend special handling of "actions" parameter group to all bindings
2 participants