Hi Philipp,
the reason I contributed the ScriptableNode interface is that the
exposure as a first-class Javascript object allows us to access often-
used features of a node in a way that feels natural to Javascript
programmers. This is not only using node.text instead of the more Java-
ish node.getProperty("text").getString(), but also for looping over
multi-value properties or child node lists, the ScriptableNode
provides a much more convenient API.
It is right, that for someone already being familiar with the JCR API,
this is not the natural way to do this, this is why the
resource.getNode() method still will give you the Java object, but it
provides a lightweight way of accessing your content repository as a
JSON object.
If there are methods you would like to see in the ScriptableNode
implementation, feel free to file a bug, I will be happy to implement
them and contribute a patch.
regards,
Lars
On 20.12.2007, at 11:57, Philipp Koch wrote:
hi,
i've been playing around with the javascript impl. (by using
microsling) quite a while. it works well, but stumbled over the
ScriptableNode object which you get by calling:
var node = request.getResource().node;
the javax.jcr.Node provides lots of methods which are not wrapped in
the ScriptableNode class (e.g. getPath()) which might be useful.
getting a property or a node is from my point of view also a bit
awkward, especially if you are familiar with the jcr api:
javascript: node.text
jcr: node.getProperty("text").getString()
ok, i see that you have to write quite a few more characters for the
jcr syntax case in order to retrieve the property (or for the nodwe
case a node).
i would nevertheless propose to drop the ScriptableNode impl because
the sling resource also provides a default mapping which does
basically what the ScriptableNode impl does. this mapped object can be
retrieved by calling request.getResource().adaptTo(Object.class).
what do others think?
regards,
philipp
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
