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

HostRule is missing type definition #345

Open
wertzui opened this issue Jun 18, 2024 · 8 comments
Open

HostRule is missing type definition #345

wertzui opened this issue Jun 18, 2024 · 8 comments
Labels
enhancement New feature or request

Comments

@wertzui
Copy link

wertzui commented Jun 18, 2024

rules.JsRule({...}); returns a HostRule, but HostRule is only defined as object with a documentation link to https://www.openhab.org/javadoc/latest/org/openhab/core/automation/rule.

It would be good if the complete type for HostRule would be provided.

@wertzui wertzui added the enhancement New feature or request label Jun 18, 2024
@florian-h05
Copy link
Contributor

IMO JSRule should rather return nothing, I don’t see a usecase where the return value is needed.

@wertzui
Copy link
Author

wertzui commented Jun 18, 2024

My use case is that I want to get the generated UID after creating the rule.

@florian-h05
Copy link
Contributor

I would rather manually set the UID of the rule than getting it afterwards.

@wertzui
Copy link
Author

wertzui commented Jun 18, 2024

And I would rather rely on the library to ensure valid and unique names 😉

@florian-h05
Copy link
Contributor

Those names are however „unpredictable“ which indeed is a problem when using the UI to manually trigger the rule.

The thing is, I don’t want do document the return value of JSRule because I don’t want to encourage users to use the returned object.
Without having a translation layer from Java to JS, users are likely to run into type problems and I don’t want to maintain this additional code.

I would instead propose to have JSRule just return the UID of the created rule.

@wertzui
Copy link
Author

wertzui commented Jun 19, 2024

Returning the UID would be fine for my use case, but it might not be for others.

What about writing a wrapper around the Java Rule interface, just as Item is a wrapper around the Java Item interface?
That would probably break less peoples code, because the wrappers methods could still have the same names as the Java Rule interface.

@florian-h05
Copy link
Contributor

What about writing a wrapper around the Java Rule interface, just as Item is a wrapper around the Java Item interface?

As said above: I don’t want to maintain this additional code, which use case I consider fairly limited.

@florian-h05
Copy link
Contributor

The raw Java rule provides:

getActions: JSRules have only one action, and this is the execute callback.
getConditions: JSRules don’t have conditions.
getConfiguration: JSRule does not set configuration, nothing to get here.
getConfigurationDescriptions: same as above
getDescription: This is what you set as descriptions, instead of getting it afterwards memorise it.
getModule: Gets a action/condition/trigger by id. See explanation above for them.
getName: same as getDescription
getTags: same as getDescription
getTemplateUid: should not be set for JSRules.
getTriggers: see above.
getUid: only useful method.
getVisibility: is always visible, method not useful.

So as you can see it is only the UID getter that is useful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants