You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Philipp Koch <ph...@day.com> on 2007/12/20 11:57:00 UTC
javascript: javax.jcr.Node vs. ScriptableNode
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
Re: javascript: javax.jcr.Node vs. ScriptableNode
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
this sounds reasonable. We should introduce a similar two-stage
wrapping for the request and response:
- request.attributes
- request.parameters
- request.cookies
- request.session
this way you could express the default behavior of Sling with
node.properties = request.parameters
regards,
Lars
On 20.12.2007, at 15:01, Felix Meschberger wrote:
> 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
>> lars@trieloff.net
>> http://weblogs.goshaky.com/weblogs/lars
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: javascript: javax.jcr.Node vs. ScriptableNode
Posted by Felix Meschberger <fm...@gmail.com>.
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
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: javascript: javax.jcr.Node vs. ScriptableNode
Posted by Lars Trieloff <la...@trieloff.net>.
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
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: javascript: javax.jcr.Node vs. ScriptableNode
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 20.12.2007, 11:57 +0100 schrieb Philipp Koch:
> 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?
+1
We could even go a step further an implement support for adapting to a
Map, which just contains the properties of the resource's node. The
child nodes need not be in the Map because you can access the child
nodes as child resources through the ResourceResolver.listChildren
method.
Regards
Felix