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
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars
