-
-
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
Add dynamic scripting-language transformation service #3487
Conversation
1bbc292
to
fa3d60b
Compare
I'll have a deeper look later but two things that I found immediately:
|
Thinking a bit more about it: If you inject the The config description provider should then be part of the |
Thanks for the feedback. I'm learning about everything as I go. I'll look into your other suggestions. In the mean time:
I was planning to do this later on because at the moment I just wanted to make them the same as any other transformation. I agree that a longer / more descriptive name is better.
The idea is to keep a static xml for Is there a better / simpler mechanism to achieve this? |
Are you referring to the actual Or are you saying that we should create a
I don't know how to inject them directly when the target filter is dynamic depending on the scriptType.
|
I meant a The |
Looks good 👍 What happens if you have both Nashorn and Graal installed? |
I've just looked into this. Although it appears do-able, it would require some changes / refactoring that would affect many things both in core and in addons which could open a new can of worms. For example, the VATTransformation has a different / custom profile class implementation. It should be tackled in a separate PR. |
Fine with me. Can you push your latest code? |
I've incorporated most of your suggestions, except:
I can inject all the transformation services using dynamic reference, and keep track of them in a list / map of some sort, but that seems like a lot of duplicate extra work when it's already being kept track of by the ScriptTransformationServiceFactory. Is there a reason why the profilefactory needs to keep its own reference independently? |
4b03a35
to
dd98143
Compare
Factories should not be used as registries, this is mixing concepts. Please have a look at jimtng#1. IMO also the |
Thanks for the help, @J-N-K! One last thing, not sure if it was by intention or not, but you omitted the profile ID and just used the language name in the label. It does look rather nice, but wondering whether we should add the ID back in to look like @florian-h05 WDYT? |
It's a very nice idea. I tried it, but I got stuck because I don't get the locale in the constructor. |
e9f79b3
to
d63c4b0
Compare
7206c5d
to
c197d79
Compare
Looks very good with JS and NASHORNJS 👍 I will adjust the WebUI PR openhab/openhab-webui#1448 as soon as this gets merged. |
OK I'll add the transformation ID back in a few minutes. |
This is how it will look - with the profile sorting PR #3491 included. Kind of looking a bit all over the place. Just a thought: should we group the SCRIPT ones together (once the profile list is sorted)? example: Bearing in mind that most people probably only have DSL and one other scripting language installed... |
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.
...g.openhab.core.transform/src/main/java/org/openhab/core/transform/TransformationService.java
Outdated
Show resolved
Hide resolved
...ipt/src/main/java/org/openhab/core/automation/module/script/ScriptTransformationService.java
Outdated
Show resolved
Hide resolved
Dictionary<String, Object> properties = new Hashtable<>(); | ||
String name = type.toUpperCase(); | ||
properties.put(TransformationService.SERVICE_PROPERTY_NAME, name); | ||
properties.put(TransformationService.SERVICE_PROPERTY_LABEL, name + " - " + languageName); |
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.
I would prefer SCRIPT Rule DSL (v1)
or SCRIPT ECMAScript 262 Edition
. This also groups them nicely with your other PR.
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 this looks nicer! changed as suggested
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.
I’d like to have the JS and NASHORNJS names still there, because they are mich easier to differ then the ECMAScript Versions, but I am fine with putting a SCRIPT in front of them.
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.
That makes the label very long and duplicates the information for all other languages. Can we modify what is returned by the script engine so it returns „ECMAScript (Nashorn, v5)“ and „ECMAScript (Graal, v11)“ or similar?
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.
I don’t think this is possible, because at least I’ve never noticed GraalJS providing the information that it is Graal.
However looking at the UI for creating new scripts, I think it would be fine if the config description contains the MIME type and UI can display the MIME type. And don’t change the label here.
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.
Alternatively we change the corresponding graaljs and nashorn bundles to somehow return those values, but that involves creating a proxy javax.script.ScriptEngineFactory unless there's a better way to do that.
Both GraalJS and NashornJS addons already have their own ScriptEngineFactory with method overrides to provide e.g. additional MIME types. See https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.automation.jsscriptingnashorn/src/main/java/org/openhab/automation/jsscriptingnashorn/internal/NashornScriptEngineFactory.java and https://github.com/openhab/openhab-addons/blob/main/bundles/org.openhab.automation.jsscripting/src/main/java/org/openhab/automation/jsscripting/internal/GraalJSScriptEngineFactory.java.
Therefore let‘s just override the getLanguageName
method there and use the languageName as in the current state of this PR. Therefore this PR should be finished.
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.
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.
Using getEngineName
IMO is too long. I‘d go for the languageName and overwrite the getLanguageName
methods in the JS bundles.
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.
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 good 👍
From my POV, this PR is finished.
This replaced SCRIPT transformation with one specific to each language e.g. JS, RB, GROOVY, etc. Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
This preserves the scriptType case instead of forcing it to lowercase Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jan N. Klug <github@klug.nrw>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
7990a14
to
3592c8e
Compare
Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au>
20cf167
to
02b521b
Compare
Rebased and merge conflicts resolved |
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.
Thanks!
Since @J-N-K already reviewed and approved it, I only had a glance over the code without actively testing it, but what I saw looks fine.
Closes #1844. * Allows to copy the UID. * Sorts the transformation types in the "by types" list alphabetically and makes the segment labels uppercase to match the transformation service names. * Adjusts to recent core change openhab/openhab-core#3487: removes the script language selection and updates the editor mode and code snippet injection. * Extends language support and refactors the translate mode logic in `script-editor.vue`. * Fixes the clear label button not displayed in create mode and displayed for non-editable transformations. * Shows a tip on how to use the transformation for Item states. * Fixes failing and not required API request after transformation creation. * Removes possibility to select and attempt to delete not-editable transformations, which is not possible and failed. Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/openhab-4-0-milestone-discussion/145133/186 |
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/preparation-for-oh-4-0-how-to-find-my-js-transformations/146233/9 |
Refs openhab/openhab-core#3487. Signed-off-by: Florian Hotze <florianh_dev@icloud.com>
This pull request has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/problem-with-graaljs-script-transformation-in-things-file/145188/11 |
* Add dynamic scripting language transformation service This replaced SCRIPT transformation with one specific to each language e.g. JS, RB, GROOVY, etc. Co-authored-by: Jan N. Klug <github@klug.nrw> Signed-off-by: Jimmy Tanagra <jcode@tanagra.id.au> GitOrigin-RevId: fbaf992
See previous discussions in #3465 and #3476
Resolve #3465
Potentially fix #3521
Documentation: openhab/openhab-docs#2042
Breaking change notice: openhab/openhab-distro#1514
Why?
SCRIPT
transformation itself is removed completely.Instead, it creates the transformation for whatever language is registered in the system:
It will only show the ones that are actually installed. Here, I have Ruby, Jython and JS Scripting installed and Groovy not installed, so GROOVY is not showing up on the list
Also note that it only shows the scripts for the selected language. Above shows only Ruby scripts, and below, only JS scripts:
The profile URI for Ruby transformation is
profile:transform:RB
which corresponds to the .rb extensionThe profile URI for JS transformation is
profile:transform:JS
which corresponds to the .js extension... and so on.
Furthermore, the configuration options can also be localised, although I can't seem to get anything (including MAP, REGEX, etc) to show any language other than English on my system, even after changing my language regional setting in openhab.
It should be compatible with the old JS transformation too. Here's my sitemap:
bro.js:
Even inline JS transformation works like it used to:
And now Ruby inline transformation works too:
And here's the result of the REST
rest/transformation/services
And the result of
rest/profile-types
(with other profile entries removed for brevity)