Hi Lars,
The problem is, that this goal collides with another well-known Rhino
behaviour where parameterless getter methods are mapped to properties,
such as node.getPath() would be node.path, etc. Having node.text as a
shortcut for node.getProperty("text") would hide one or the other in
case of a collision.
To overcome this proble, we might either provide an object
node.properties which allows access to the properties (and node.children
for child nodes) and then we are able to map the other API of the Node
class as expected. Examples of such mappings might be :
Node.getPath() ----- node.path
Node.getName() ----- node.name
Node.getProperty("x") ----- node.properties.x
Node.getNode("y") ----- node.children.y
Or else the other mechanism of adapting the node to a Map (or Object)
WDYT ?
Regards
Felix
Am Donnerstag, den 20.12.2007, 14:38 +0100 schrieb Lars Trieloff:
> 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
>
