-
-
Notifications
You must be signed in to change notification settings - Fork 428
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 a generic script transformation #2883
Conversation
255c8b2
to
ca8c400
Compare
I don‘t understand why this happens. Every second local build fails if I don‘t use - |
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 for the PR! I finally got some time to test it and got it working with my JSScripting (Nashorn) add-on on Java 17. 👍 I did find a small issue while testing:
...ipt/src/main/java/org/openhab/core/automation/module/script/ScriptTransformationService.java
Show resolved
Hide resolved
One additional functionality that the existing JavaScript transformation has is that you can supply additional parameters used in scripts. See also the examples documentation:
Maybe it is also possible to implement this so this new transformation has feature parity and there is no good reason to keep using the existing JavaScript transformation. 😉 |
Good idea. The nice thing is that this also works with other languages. |
Yes it works very well! So far I've tested Groovy, JS (Graal) and JS (Nashorn) transformations in parallel on Java 17. 🙂 |
Signed-off-by: Jan N. Klug <[email protected]>
Signed-off-by: Jan N. Klug <[email protected]>
Signed-off-by: Jan N. Klug <[email protected]>
9d4827f
to
fbdd2c9
Compare
There is one other feature missing, but I'm not sure if we should implement that: inline scripts. |
Maybe that is something for a follow up PR. E.g. In that case the |
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.
Many thanks! 👍
Your last comment brought my attention to potential leaking memory when script engines are not properly disposed. In |
Yes it would certainly help to prevent any potential memory leak. 👍 |
Is this actually documented anywhere? |
Unfortunately there is no good place where to put that documentation. I can provide the content if someone finds a place to put it. |
I would expect it to find information about this in the Transformations page under Configuration, unless I'm misunderstanding what documentation is being asked about here. That's at least the first place I'd personally look for documentation about transformation capabilities provided by core. |
Just because the Transformations Configuration is generic now doesn't mean we can't go as specific as necessary. I don't think this warrants inventing a whole new page to support it. I agree that we can't put it under add-ons not only because it's generated automatically but also because this isn't an add-on, it's part of core. I look at this similarly to Ephemeris. The docs for it didn't really "belong" anywhere either. But short of creating a new page just for it, placing the docs for it on the Actions page was the best we could manage. I'm still not happy with that but it was the best we could do. I think this is a similar situation. It doesn't really fit the page now but there really isn't anywhere else to put it. And it's not wholly unexpected to look there. The docs shouldn't need to go into to too many specific details on syntax. We can push that on the references for the specific languages I think. But the generic stuff like "it supports all the languages installed", the files need to go into the transformation folder, the tranformation should be wrapped in a function that takes one argument and returns the result as Strings (is this true?), stuff like that. An example or two would be nice but may not even be necessary. |
I totally agree on Rich’s opinion here, IMO it is not the perfect place. This feature is just to good to keep it undocumented because it’s docs do not really fit into the existing docs. So, let’s put a general, language-independent section about the generic script transformation with one/two examples there, I can then take care of adding a example to the JS Scripting add-on docs. |
@J-N-K Does the SCRIPT transformation work for you when you follow your docs? For me it is always failing with |
No. But |
Thx, now it‘s working. The docs were not clear enough to me, maybe I should improve them a little bit. The SCRIPT transformation is using Nashorn, right? |
Use |
If you use Java 17 there will be no Nashorn. 😉 |
I could have come up with that myself, but the alias for RhinoJS confused me a bit.
When we switch to Java 17 and Nashorn leaves us, JS Scripting can take over the |
But it works fine with your Nashorn-addon (which should IMO be merged to openhab-addons after we switch to Java 17). The Groovy add-on also accepts |
Thats the question: After switching to Java 17, should we continue to use Nashorn for transformation or install JS Scripting by default and use JS Scripting for the |
IMO the alias will not affect that decision, but would be much easier for all those using 3.4 (which as last version of 3.x will probably be around for quite a while, if we look at the number of questions we still receive for 2.5). |
You are right, I‘ll have a look at introducing an alias, let‘s take your proposal |
The extra mime type would certainly be nice for people who transition from Nashorn to GraalJS... or from GraalJS to something else whenever that goes EOL. I'm all for adding JSScripting (Nashorn) to the addons repo so it is easier to optionally install it after an upgrade. 🙂 |
Reference openhab/openhab-core#2883. The "graaljs" MIME type is introduced in openhab/openhab-addons#13851. Please note that the transformation docs link might not work now, as the doc updates aren't published yet. Signed-off-by: Florian Hotze <[email protected]>
* README: Add `SCRIPT` transformation Reference openhab/openhab-core#2883. The "graaljs" MIME type is introduced in openhab/openhab-addons#13851. Please note that the transformation docs link might not work now, as the doc updates aren't published yet. * README: Use var instead of const and let in examples Usage of const and let lead to problems in UI scripts and therefore the examples should not use them. Signed-off-by: Florian Hotze <[email protected]>
Signed-off-by: Jan N. Klug <[email protected]> GitOrigin-RevId: a192a1d
Depends on #2821
Related to #2872
Signed-off-by: Jan N. Klug [email protected]