Hi,
I think you've to use one of these: POJO/bean-style property support,
JSAdapter or JSObject.
BTW, JSObject does not have to be per object. You could accept any Java
type value in your AbstractJSObject subclass and delegate the
calls/property accesses to it.
For example, you could use reflection to look for specific name pattern
in that given Java object and forward property/method access
accordingly. Or you could have your own annotations and forward JS
property/method access based on annotations (from your JSObject
implementation).
Yes, this means that you've to write a bit of glue layer code.
Other thing to consider is Object.bindProperties function (another
nashorn extension). This lets you to "bind" properties of one object to
another object. You could write customer wrapper function that binds
your Java object's properties and then add/remove properties.
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Object.bindProperties
Thanks,
-Sundar
On Tuesday 16 June 2015 01:31 PM, Radu Cotescu wrote:
Hi Sundar,
Thank you for your quick reply! I did read about JSAdapter and JSObject
before my initial email but I don't think they actually do what I want.
In my use-case I need to be able to interfere with object translation (from
Java to JavaScript) for all instances of a certain Java class, not just for
specific objects. Is there any way I could achieve this (something similar
to Rhino's host objects [2])?
Thanks,
Radu
[2] -
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Rhino/Embedding_tutorial#JavaScript_host_objects
On Mon, 15 Jun 2015 at 15:23 A. Sundararajan <
sundararajan.athijegannat...@oracle.com> wrote:
Please note that nashorn has support to handle Java objects with 'bean
style' property support. And you could implement Java interfaces and
extend Java abstract classes in script. java.util.Map objects are
treated specially to provide key-value access as properties.
java.util.ArrayList objects are treated like arrays (indexed element
access, length property for size). These could be used provide
script-friendly access to your existing Java classes.
But, if you want to write script "proxies" to trap property access etc.,
then there are two ways:
1) JSAdapter - you'd write JSAdapter wrapper in script.
Example:
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-JSAdapterconstructor
2) Implementing jdk.nashorn.api.scripting.JSObject.
https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/JSObject.html
AbstractJSObject (
https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/AbstractJSObject.html
) provides empty/null implementation for most methods and so you can
extend it as well.
In addition, any @FunctionalInterface object
(java.util.functions.Function etc) can be called as a script function.
So, your script functions could just be Java functional interface objects.
Example:
https://wiki.openjdk.java.net/display/Nashorn/Nashorn+extensions#Nashornextensions-Plugging-inyourownJSObject
Hope this helps,
-Sundar
On Monday 15 June 2015 05:42 PM, Radu Cotescu wrote:
Hello,
I've recently started looking into replacing Rhino with Nashorn as the
JavaScript scripting engine for Apache Sling (see SLING-4801 [0]).
Once nice Rhino feature that I don't seem to be able to easily map to
something from Nashorn is the ability to provide my own object wrappers,
such that the resulting JS object contains some custom properties. I did
notice this thread [1] but I wasn't able to reach to a conclusion
regarding
this feature.
Is there a way to easily implement this custom object translation layer
without having to implement a JSObject? The problem with this approach is
that Sling script developers will have to use these custom wrapper
classes
(JSObjects) instead of the APIs directly available through the Bindings,
making scripts written for the Rhino implementation incompatible.
Thanks,
Radu
[0] - https://issues.apache.org/jira/browse/SLING-4801
[1] -
https://www.mail-archive.com/nashorn-dev%40openjdk.java.net/msg01485.html
