You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Michael Marth (JIRA)" <ji...@apache.org> on 2008/03/13 17:40:25 UTC
[jira] Created: (SLING-328) access to node props in esp
access to node props in esp
---------------------------
Key: SLING-328
URL: https://issues.apache.org/jira/browse/SLING-328
Project: Sling
Issue Type: Bug
Reporter: Michael Marth
My .esp looks like
for (var i in currentNode.getNodes()) {
if(currentNode.getNodes()[i].getProperty("approved").getString() == "true") {
...
Bertrand tells me that in the second line this should work as well:
if(currentNode.getNodes()[i].approved (...)
It does not give an exception but the property is undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Lars Trieloff <la...@trieloff.net>.
I agree, this should be fixed. The methods of the ScriptableNode
object should be as close as possible to the spec, if you want to
access the properties and child nodes using Javascript language
features, you can still use properties of the objects.
On 14.03.2008, at 08:54, Carsten Ziegeler wrote:
> Felix Meschberger wrote:
>> Hi all,
>> This issue and SLING-329 give raise to an interesting question: The
>> ScriptableNode implements the ECMA getNodes() method returning an
>> EMCA
>> object containing all properties. This is fundamentally different
>> from
>> the spec which says an Iterator is returned.
>> In fact, it completely breaks my knowledge of JCR in that I would
>> not be
>> able to iterate as I would expect it: while (iter.hasNext()) { Node
>> n =
>> iter.next(); }
>> In addition, this might also be a performance hog because the
>> constructor of the respective object iterates the complete JCR
>> iterator
>> to build the object (this is probably required for the
>> implementation).
>> So what are the opinions out there on this break in API ?
> I think this should be fixed according to the spec; we stay
> compatible with Java and avoid performance problems.
>
> Carsten
>
>> Regards
>> Felix
>> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
>> (JIRA):
>>> access to node props in esp
>>> ---------------------------
>>>
>>> Key: SLING-328
>>> URL: https://issues.apache.org/jira/browse/SLING-328
>>> Project: Sling
>>> Issue Type: Bug
>>> Reporter: Michael Marth
>>>
>>>
>>> My .esp looks like
>>>
>>> for (var i in currentNode.getNodes()) {
>>> if(currentNode.getNodes()
>>> [i].getProperty("approved").getString() == "true") {
>>> ...
>>>
>>> Bertrand tells me that in the second line this should work as well:
>>> if(currentNode.getNodes()[i].approved (...)
>>> It does not give an exception but the property is undefined.
>>>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Carsten Ziegeler <cz...@apache.org>.
Felix Meschberger wrote:
> Hi all,
>
> This issue and SLING-329 give raise to an interesting question: The
> ScriptableNode implements the ECMA getNodes() method returning an EMCA
> object containing all properties. This is fundamentally different from
> the spec which says an Iterator is returned.
>
> In fact, it completely breaks my knowledge of JCR in that I would not be
> able to iterate as I would expect it: while (iter.hasNext()) { Node n =
> iter.next(); }
>
> In addition, this might also be a performance hog because the
> constructor of the respective object iterates the complete JCR iterator
> to build the object (this is probably required for the implementation).
>
> So what are the opinions out there on this break in API ?
I think this should be fixed according to the spec; we stay compatible
with Java and avoid performance problems.
Carsten
>
> Regards
> Felix
>
>
> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth (JIRA):
>> access to node props in esp
>> ---------------------------
>>
>> Key: SLING-328
>> URL: https://issues.apache.org/jira/browse/SLING-328
>> Project: Sling
>> Issue Type: Bug
>> Reporter: Michael Marth
>>
>>
>> My .esp looks like
>>
>> for (var i in currentNode.getNodes()) {
>> if(currentNode.getNodes()[i].getProperty("approved").getString() == "true") {
>> ...
>>
>> Bertrand tells me that in the second line this should work as well:
>> if(currentNode.getNodes()[i].approved (...)
>> It does not give an exception but the property is undefined.
>>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
It took some time for me to really find out, what is wrong in the code
provided by SLING-329 and SLING-328: It is the use of the getNodes()
method to actually get a map of nodes.
To go JavaScript, the ScriptableNode wrapping the Node interface for use
in JavaScript, supports iterating all properties and child nodes of a
node just by doing:
for (var label in currentNode) {
var item = currentNode[label];
if (item.isNode()) {
... use the item as a node ...
}
}
Using this mechanism, the getNodes() may still comply with the official
JCR API and be an iterator and nothing more.
To support just listing nodes and properties, we might add new
properties "nodes" and "properties" which achieve what is currently
achieved by the method getNodes() and getProperties(): Return a map of
child nodes and properties. In fact it is more like JavaScript and does
not clash with defined API.
WDYT ?
Regards
Felix
Am Freitag, den 14.03.2008, 08:31 +0100 schrieb Felix Meschberger:
> Hi all,
>
> This issue and SLING-329 give raise to an interesting question: The
> ScriptableNode implements the ECMA getNodes() method returning an EMCA
> object containing all properties. This is fundamentally different from
> the spec which says an Iterator is returned.
>
> In fact, it completely breaks my knowledge of JCR in that I would not be
> able to iterate as I would expect it: while (iter.hasNext()) { Node n =
> iter.next(); }
>
> In addition, this might also be a performance hog because the
> constructor of the respective object iterates the complete JCR iterator
> to build the object (this is probably required for the implementation).
>
> So what are the opinions out there on this break in API ?
>
> Regards
> Felix
>
>
> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth (JIRA):
> > access to node props in esp
> > ---------------------------
> >
> > Key: SLING-328
> > URL: https://issues.apache.org/jira/browse/SLING-328
> > Project: Sling
> > Issue Type: Bug
> > Reporter: Michael Marth
> >
> >
> > My .esp looks like
> >
> > for (var i in currentNode.getNodes()) {
> > if(currentNode.getNodes()[i].getProperty("approved").getString() == "true") {
> > ...
> >
> > Bertrand tells me that in the second line this should work as well:
> > if(currentNode.getNodes()[i].approved (...)
> > It does not give an exception but the property is undefined.
> >
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 14.03.2008, 10:35 +0100 schrieb Lars Trieloff:
> Right, but you can move the code from the iterator to the individual
> methods to provide lazy loading access to elements of the iterator.
This will only work if you do access the child nodes only directly. If
you create a loop with
for (var x in children)
the getIds() method is called to get the list of indices. So you just
delay the complete iteration from the constructor to the getIds call ...
Regards
Felix
>
> On 14.03.2008, at 10:22, Felix Meschberger wrote:
>
> > Hi Lars,
> >
> > Am Freitag, den 14.03.2008, 10:07 +0100 schrieb Lars Trieloff:
> >> Hi Felix,
> >>
> >> I just had a look at the implementation of ScriptableItemMap and the
> >> implementation is quite elegant, performance-wise, there are only two
> >> minor issues:
> >> - it does not expose the Iterator interface
> >> - returned items are not casted into scriptablenode and
> >> scriptableproperty if possible.
> >
> > The performance issue comes from the constructor which walks along the
> > iterator upfront. The goal of an iterator is, that we do not have to
> > walk it upfront.
> >
> > Of course, the script example provided in SLING-328 is also
> > problematic
> > as it causes the constructor to be called on each loop iteration
> > causing
> > the child node iterator to be walked n^2 times (n is the number of
> > child
> > nodes)....
> >
> >>
> >> these two things are quite easy to fix which would allow using the
> >> API
> >> in a spec-conformant way and in a way that can be used with
> >> Javascript
> >> for loops, etc.
> >
> > As I alwas say: I am ok with supporting JavaScript syntax but I am not
> > ok with adding more API, which does not exist elsewhere. This will
> > just
> > create issues.... Therefore, I am really for removing this
> > functionality.
> >
> > Regards
> > Felix
> >
> >>
> >> regards,
> >>
> >> Lars
> >>
> >> On 14.03.2008, at 08:31, Felix Meschberger wrote:
> >>
> >>> Hi all,
> >>>
> >>> This issue and SLING-329 give raise to an interesting question: The
> >>> ScriptableNode implements the ECMA getNodes() method returning an
> >>> EMCA
> >>> object containing all properties. This is fundamentally different
> >>> from
> >>> the spec which says an Iterator is returned.
> >>>
> >>> In fact, it completely breaks my knowledge of JCR in that I would
> >>> not be
> >>> able to iterate as I would expect it: while (iter.hasNext()) { Node
> >>> n =
> >>> iter.next(); }
> >>>
> >>> In addition, this might also be a performance hog because the
> >>> constructor of the respective object iterates the complete JCR
> >>> iterator
> >>> to build the object (this is probably required for the
> >>> implementation).
> >>>
> >>> So what are the opinions out there on this break in API ?
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>
> >>> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
> >>> (JIRA):
> >>>> access to node props in esp
> >>>> ---------------------------
> >>>>
> >>>> Key: SLING-328
> >>>> URL: https://issues.apache.org/jira/browse/SLING-328
> >>>> Project: Sling
> >>>> Issue Type: Bug
> >>>> Reporter: Michael Marth
> >>>>
> >>>>
> >>>> My .esp looks like
> >>>>
> >>>> for (var i in currentNode.getNodes()) {
> >>>> if(currentNode.getNodes()
> >>>> [i].getProperty("approved").getString() == "true") {
> >>>> ...
> >>>>
> >>>> Bertrand tells me that in the second line this should work as well:
> >>>> if(currentNode.getNodes()[i].approved (...)
> >>>> It does not give an exception but the property is undefined.
> >>>>
> >>>
> >>
> >> --
> >> Lars Trieloff
> >> lars@trieloff.net
> >> http://weblogs.goshaky.com/weblogs/lars
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 14.03.2008, 12:01 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I see your point, but (as you know) I do not agree. The Java Content
> Repository Spec consists of two parts
> - definition of a content repository meta-model and semantics
> - mapping this meta-model and semantics to the Java language
> The second part is only of limited use when bringing the meta-model
> and semantics to another language such as Javascript (and others). My
> point is that as long as we stick to the spec in terms of the meta-
> model and the semantics, we can and should encourage language-specific
> implementations and not attempt (and fail) to translate the Java API
> 1:1 to another language.
Agreed, with a subtle point: We MUST not change the semantics of a
return value.
>
> The iterator issue is a good example: Iterators are a memory-efficient
> implementation of lists,
This is in fact not completely correct. An Iterator is an interface,
which allows iterating over multiple things. I try to be as abstract as
possible by intent. Because iterators are not limited to iterating over
lists, you can iterate over Sets (in fact the iterator() method is
defined on the Collection interface) or something completely different,
which need not be actually exist as a list but some transient situation.
> and the iterator interface is quite common in
> the Java language.
Or better yet: "iterator interface is quite common in Java
applications". Because Iterator is an interface and NOT part of the
language specification, it is part of platform API specification. In
JavaScript terms, this would be a host object.
And noone will ever prevent adding such a thing, right ?
> For Javascript, a language where iterators are
> seldom used and arrays quite often,
Well, not quite. The "for(var in object)" construct can be seen as an
iterator over the object properties.
> the best implementation of the
> meta-model and semantics would be an array that is backed by an
> Iterator to provide lazy-loading, memory efficient random access to a
> list of nodes.
Not the best, put one possible implementation. You can still directly
address the child nodes from the parent node using either
getNode(String) or the property accessor method, such as
node["childNode"]. So we do not even have to invent something else.
>
> I can fully understand that you feel uncomfortable with the idea of
> maintaining a second implementation of the JCR spec, especially in a
> language that is in many regards different from Java.
We are not maintaining a second implementation, we are maintaining a
wrapper to allow support for some JavaScript constructs such as child
node and property access through sime indexing as in node["childNode"]
(instead of node.getNode("childNode")). But this is syntactic sugar I do
not oppose (as long as it is well-done)
> But in fact, we
> are already doing it with the Sling Client Library, which from my own
> experience provides a mapping of concepts and semantics of JCR into
> Javascript that "feels" right and allows for high developer usability.
> The huge opportunity we have at the server is creating a mix of both
> approaches: we can implement getters and setters, have Java-style
> methods side-by-side with Javascript-style properties and functions
> and can benefit from lazy loading and deferred repository access. From
> my point of view this is an opportunity we cannot leave untapped.
>
> My proposal for approaching this problem would be the creation of a
> checklist for API validation:
> 1. does the API implement the concepts and meta-models of the JCR spec
> 2. does the API expose, if possible, all methods defined in the Java
> implementation of the API
and 2a. do the API signatures match ?
E.g. I know getNodes() returns an iterator, so I call hasNext() and
next() on its result.
> 3. does the API allow access to the repository without introducing
> concepts that are foreign to this programming environment.
Regards
Felix
>
> regards,
>
> Lars
>
> On 14.03.2008, at 10:41, Felix Meschberger wrote:
>
> > Hi,
> >
> > Am Freitag, den 14.03.2008, 10:35 +0100 schrieb Lars Trieloff:
> >> Right, but you can move the code from the iterator to the individual
> >> methods to provide lazy loading access to elements of the iterator.
> >
> > Right.
> >
> > But still the API question remains ;-) And of course the invitation
> > to a
> > problematic style of use as exhibited by the sample excerpt.
> >
> > My point is: This is an extension to spec only available in a tiny
> > location ... And we should not do that.
> >
> > Regards
> > Felix
> >
> >>
> >> On 14.03.2008, at 10:22, Felix Meschberger wrote:
> >>
> >>> Hi Lars,
> >>>
> >>> Am Freitag, den 14.03.2008, 10:07 +0100 schrieb Lars Trieloff:
> >>>> Hi Felix,
> >>>>
> >>>> I just had a look at the implementation of ScriptableItemMap and
> >>>> the
> >>>> implementation is quite elegant, performance-wise, there are only
> >>>> two
> >>>> minor issues:
> >>>> - it does not expose the Iterator interface
> >>>> - returned items are not casted into scriptablenode and
> >>>> scriptableproperty if possible.
> >>>
> >>> The performance issue comes from the constructor which walks along
> >>> the
> >>> iterator upfront. The goal of an iterator is, that we do not have to
> >>> walk it upfront.
> >>>
> >>> Of course, the script example provided in SLING-328 is also
> >>> problematic
> >>> as it causes the constructor to be called on each loop iteration
> >>> causing
> >>> the child node iterator to be walked n^2 times (n is the number of
> >>> child
> >>> nodes)....
> >>>
> >>>>
> >>>> these two things are quite easy to fix which would allow using the
> >>>> API
> >>>> in a spec-conformant way and in a way that can be used with
> >>>> Javascript
> >>>> for loops, etc.
> >>>
> >>> As I alwas say: I am ok with supporting JavaScript syntax but I am
> >>> not
> >>> ok with adding more API, which does not exist elsewhere. This will
> >>> just
> >>> create issues.... Therefore, I am really for removing this
> >>> functionality.
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>>
> >>>> regards,
> >>>>
> >>>> Lars
> >>>>
> >>>> On 14.03.2008, at 08:31, Felix Meschberger wrote:
> >>>>
> >>>>> Hi all,
> >>>>>
> >>>>> This issue and SLING-329 give raise to an interesting question:
> >>>>> The
> >>>>> ScriptableNode implements the ECMA getNodes() method returning an
> >>>>> EMCA
> >>>>> object containing all properties. This is fundamentally different
> >>>>> from
> >>>>> the spec which says an Iterator is returned.
> >>>>>
> >>>>> In fact, it completely breaks my knowledge of JCR in that I would
> >>>>> not be
> >>>>> able to iterate as I would expect it: while (iter.hasNext())
> >>>>> { Node
> >>>>> n =
> >>>>> iter.next(); }
> >>>>>
> >>>>> In addition, this might also be a performance hog because the
> >>>>> constructor of the respective object iterates the complete JCR
> >>>>> iterator
> >>>>> to build the object (this is probably required for the
> >>>>> implementation).
> >>>>>
> >>>>> So what are the opinions out there on this break in API ?
> >>>>>
> >>>>> Regards
> >>>>> Felix
> >>>>>
> >>>>>
> >>>>> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
> >>>>> (JIRA):
> >>>>>> access to node props in esp
> >>>>>> ---------------------------
> >>>>>>
> >>>>>> Key: SLING-328
> >>>>>> URL: https://issues.apache.org/jira/browse/
> >>>>>> SLING-328
> >>>>>> Project: Sling
> >>>>>> Issue Type: Bug
> >>>>>> Reporter: Michael Marth
> >>>>>>
> >>>>>>
> >>>>>> My .esp looks like
> >>>>>>
> >>>>>> for (var i in currentNode.getNodes()) {
> >>>>>> if(currentNode.getNodes()
> >>>>>> [i].getProperty("approved").getString() == "true") {
> >>>>>> ...
> >>>>>>
> >>>>>> Bertrand tells me that in the second line this should work as
> >>>>>> well:
> >>>>>> if(currentNode.getNodes()[i].approved (...)
> >>>>>> It does not give an exception but the property is undefined.
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> Lars Trieloff
> >>>> lars@trieloff.net
> >>>> http://weblogs.goshaky.com/weblogs/lars
> >>>>
> >>>
> >>
> >> --
> >> Lars Trieloff
> >> lars@trieloff.net
> >> http://weblogs.goshaky.com/weblogs/lars
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
I see your point, but (as you know) I do not agree. The Java Content
Repository Spec consists of two parts
- definition of a content repository meta-model and semantics
- mapping this meta-model and semantics to the Java language
The second part is only of limited use when bringing the meta-model
and semantics to another language such as Javascript (and others). My
point is that as long as we stick to the spec in terms of the meta-
model and the semantics, we can and should encourage language-specific
implementations and not attempt (and fail) to translate the Java API
1:1 to another language.
The iterator issue is a good example: Iterators are a memory-efficient
implementation of lists, and the iterator interface is quite common in
the Java language. For Javascript, a language where iterators are
seldom used and arrays quite often, the best implementation of the
meta-model and semantics would be an array that is backed by an
Iterator to provide lazy-loading, memory efficient random access to a
list of nodes.
I can fully understand that you feel uncomfortable with the idea of
maintaining a second implementation of the JCR spec, especially in a
language that is in many regards different from Java. But in fact, we
are already doing it with the Sling Client Library, which from my own
experience provides a mapping of concepts and semantics of JCR into
Javascript that "feels" right and allows for high developer usability.
The huge opportunity we have at the server is creating a mix of both
approaches: we can implement getters and setters, have Java-style
methods side-by-side with Javascript-style properties and functions
and can benefit from lazy loading and deferred repository access. From
my point of view this is an opportunity we cannot leave untapped.
My proposal for approaching this problem would be the creation of a
checklist for API validation:
1. does the API implement the concepts and meta-models of the JCR spec
2. does the API expose, if possible, all methods defined in the Java
implementation of the API
3. does the API allow access to the repository without introducing
concepts that are foreign to this programming environment.
regards,
Lars
On 14.03.2008, at 10:41, Felix Meschberger wrote:
> Hi,
>
> Am Freitag, den 14.03.2008, 10:35 +0100 schrieb Lars Trieloff:
>> Right, but you can move the code from the iterator to the individual
>> methods to provide lazy loading access to elements of the iterator.
>
> Right.
>
> But still the API question remains ;-) And of course the invitation
> to a
> problematic style of use as exhibited by the sample excerpt.
>
> My point is: This is an extension to spec only available in a tiny
> location ... And we should not do that.
>
> Regards
> Felix
>
>>
>> On 14.03.2008, at 10:22, Felix Meschberger wrote:
>>
>>> Hi Lars,
>>>
>>> Am Freitag, den 14.03.2008, 10:07 +0100 schrieb Lars Trieloff:
>>>> Hi Felix,
>>>>
>>>> I just had a look at the implementation of ScriptableItemMap and
>>>> the
>>>> implementation is quite elegant, performance-wise, there are only
>>>> two
>>>> minor issues:
>>>> - it does not expose the Iterator interface
>>>> - returned items are not casted into scriptablenode and
>>>> scriptableproperty if possible.
>>>
>>> The performance issue comes from the constructor which walks along
>>> the
>>> iterator upfront. The goal of an iterator is, that we do not have to
>>> walk it upfront.
>>>
>>> Of course, the script example provided in SLING-328 is also
>>> problematic
>>> as it causes the constructor to be called on each loop iteration
>>> causing
>>> the child node iterator to be walked n^2 times (n is the number of
>>> child
>>> nodes)....
>>>
>>>>
>>>> these two things are quite easy to fix which would allow using the
>>>> API
>>>> in a spec-conformant way and in a way that can be used with
>>>> Javascript
>>>> for loops, etc.
>>>
>>> As I alwas say: I am ok with supporting JavaScript syntax but I am
>>> not
>>> ok with adding more API, which does not exist elsewhere. This will
>>> just
>>> create issues.... Therefore, I am really for removing this
>>> functionality.
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> regards,
>>>>
>>>> Lars
>>>>
>>>> On 14.03.2008, at 08:31, Felix Meschberger wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> This issue and SLING-329 give raise to an interesting question:
>>>>> The
>>>>> ScriptableNode implements the ECMA getNodes() method returning an
>>>>> EMCA
>>>>> object containing all properties. This is fundamentally different
>>>>> from
>>>>> the spec which says an Iterator is returned.
>>>>>
>>>>> In fact, it completely breaks my knowledge of JCR in that I would
>>>>> not be
>>>>> able to iterate as I would expect it: while (iter.hasNext())
>>>>> { Node
>>>>> n =
>>>>> iter.next(); }
>>>>>
>>>>> In addition, this might also be a performance hog because the
>>>>> constructor of the respective object iterates the complete JCR
>>>>> iterator
>>>>> to build the object (this is probably required for the
>>>>> implementation).
>>>>>
>>>>> So what are the opinions out there on this break in API ?
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>>
>>>>> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
>>>>> (JIRA):
>>>>>> access to node props in esp
>>>>>> ---------------------------
>>>>>>
>>>>>> Key: SLING-328
>>>>>> URL: https://issues.apache.org/jira/browse/
>>>>>> SLING-328
>>>>>> Project: Sling
>>>>>> Issue Type: Bug
>>>>>> Reporter: Michael Marth
>>>>>>
>>>>>>
>>>>>> My .esp looks like
>>>>>>
>>>>>> for (var i in currentNode.getNodes()) {
>>>>>> if(currentNode.getNodes()
>>>>>> [i].getProperty("approved").getString() == "true") {
>>>>>> ...
>>>>>>
>>>>>> Bertrand tells me that in the second line this should work as
>>>>>> well:
>>>>>> if(currentNode.getNodes()[i].approved (...)
>>>>>> It does not give an exception but the property is undefined.
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Lars Trieloff
>>>> lars@trieloff.net
>>>> http://weblogs.goshaky.com/weblogs/lars
>>>>
>>>
>>
>> --
>> Lars Trieloff
>> lars@trieloff.net
>> http://weblogs.goshaky.com/weblogs/lars
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Freitag, den 14.03.2008, 10:35 +0100 schrieb Lars Trieloff:
> Right, but you can move the code from the iterator to the individual
> methods to provide lazy loading access to elements of the iterator.
Right.
But still the API question remains ;-) And of course the invitation to a
problematic style of use as exhibited by the sample excerpt.
My point is: This is an extension to spec only available in a tiny
location ... And we should not do that.
Regards
Felix
>
> On 14.03.2008, at 10:22, Felix Meschberger wrote:
>
> > Hi Lars,
> >
> > Am Freitag, den 14.03.2008, 10:07 +0100 schrieb Lars Trieloff:
> >> Hi Felix,
> >>
> >> I just had a look at the implementation of ScriptableItemMap and the
> >> implementation is quite elegant, performance-wise, there are only two
> >> minor issues:
> >> - it does not expose the Iterator interface
> >> - returned items are not casted into scriptablenode and
> >> scriptableproperty if possible.
> >
> > The performance issue comes from the constructor which walks along the
> > iterator upfront. The goal of an iterator is, that we do not have to
> > walk it upfront.
> >
> > Of course, the script example provided in SLING-328 is also
> > problematic
> > as it causes the constructor to be called on each loop iteration
> > causing
> > the child node iterator to be walked n^2 times (n is the number of
> > child
> > nodes)....
> >
> >>
> >> these two things are quite easy to fix which would allow using the
> >> API
> >> in a spec-conformant way and in a way that can be used with
> >> Javascript
> >> for loops, etc.
> >
> > As I alwas say: I am ok with supporting JavaScript syntax but I am not
> > ok with adding more API, which does not exist elsewhere. This will
> > just
> > create issues.... Therefore, I am really for removing this
> > functionality.
> >
> > Regards
> > Felix
> >
> >>
> >> regards,
> >>
> >> Lars
> >>
> >> On 14.03.2008, at 08:31, Felix Meschberger wrote:
> >>
> >>> Hi all,
> >>>
> >>> This issue and SLING-329 give raise to an interesting question: The
> >>> ScriptableNode implements the ECMA getNodes() method returning an
> >>> EMCA
> >>> object containing all properties. This is fundamentally different
> >>> from
> >>> the spec which says an Iterator is returned.
> >>>
> >>> In fact, it completely breaks my knowledge of JCR in that I would
> >>> not be
> >>> able to iterate as I would expect it: while (iter.hasNext()) { Node
> >>> n =
> >>> iter.next(); }
> >>>
> >>> In addition, this might also be a performance hog because the
> >>> constructor of the respective object iterates the complete JCR
> >>> iterator
> >>> to build the object (this is probably required for the
> >>> implementation).
> >>>
> >>> So what are the opinions out there on this break in API ?
> >>>
> >>> Regards
> >>> Felix
> >>>
> >>>
> >>> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
> >>> (JIRA):
> >>>> access to node props in esp
> >>>> ---------------------------
> >>>>
> >>>> Key: SLING-328
> >>>> URL: https://issues.apache.org/jira/browse/SLING-328
> >>>> Project: Sling
> >>>> Issue Type: Bug
> >>>> Reporter: Michael Marth
> >>>>
> >>>>
> >>>> My .esp looks like
> >>>>
> >>>> for (var i in currentNode.getNodes()) {
> >>>> if(currentNode.getNodes()
> >>>> [i].getProperty("approved").getString() == "true") {
> >>>> ...
> >>>>
> >>>> Bertrand tells me that in the second line this should work as well:
> >>>> if(currentNode.getNodes()[i].approved (...)
> >>>> It does not give an exception but the property is undefined.
> >>>>
> >>>
> >>
> >> --
> >> Lars Trieloff
> >> lars@trieloff.net
> >> http://weblogs.goshaky.com/weblogs/lars
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Lars Trieloff <la...@trieloff.net>.
Right, but you can move the code from the iterator to the individual
methods to provide lazy loading access to elements of the iterator.
On 14.03.2008, at 10:22, Felix Meschberger wrote:
> Hi Lars,
>
> Am Freitag, den 14.03.2008, 10:07 +0100 schrieb Lars Trieloff:
>> Hi Felix,
>>
>> I just had a look at the implementation of ScriptableItemMap and the
>> implementation is quite elegant, performance-wise, there are only two
>> minor issues:
>> - it does not expose the Iterator interface
>> - returned items are not casted into scriptablenode and
>> scriptableproperty if possible.
>
> The performance issue comes from the constructor which walks along the
> iterator upfront. The goal of an iterator is, that we do not have to
> walk it upfront.
>
> Of course, the script example provided in SLING-328 is also
> problematic
> as it causes the constructor to be called on each loop iteration
> causing
> the child node iterator to be walked n^2 times (n is the number of
> child
> nodes)....
>
>>
>> these two things are quite easy to fix which would allow using the
>> API
>> in a spec-conformant way and in a way that can be used with
>> Javascript
>> for loops, etc.
>
> As I alwas say: I am ok with supporting JavaScript syntax but I am not
> ok with adding more API, which does not exist elsewhere. This will
> just
> create issues.... Therefore, I am really for removing this
> functionality.
>
> Regards
> Felix
>
>>
>> regards,
>>
>> Lars
>>
>> On 14.03.2008, at 08:31, Felix Meschberger wrote:
>>
>>> Hi all,
>>>
>>> This issue and SLING-329 give raise to an interesting question: The
>>> ScriptableNode implements the ECMA getNodes() method returning an
>>> EMCA
>>> object containing all properties. This is fundamentally different
>>> from
>>> the spec which says an Iterator is returned.
>>>
>>> In fact, it completely breaks my knowledge of JCR in that I would
>>> not be
>>> able to iterate as I would expect it: while (iter.hasNext()) { Node
>>> n =
>>> iter.next(); }
>>>
>>> In addition, this might also be a performance hog because the
>>> constructor of the respective object iterates the complete JCR
>>> iterator
>>> to build the object (this is probably required for the
>>> implementation).
>>>
>>> So what are the opinions out there on this break in API ?
>>>
>>> Regards
>>> Felix
>>>
>>>
>>> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
>>> (JIRA):
>>>> access to node props in esp
>>>> ---------------------------
>>>>
>>>> Key: SLING-328
>>>> URL: https://issues.apache.org/jira/browse/SLING-328
>>>> Project: Sling
>>>> Issue Type: Bug
>>>> Reporter: Michael Marth
>>>>
>>>>
>>>> My .esp looks like
>>>>
>>>> for (var i in currentNode.getNodes()) {
>>>> if(currentNode.getNodes()
>>>> [i].getProperty("approved").getString() == "true") {
>>>> ...
>>>>
>>>> Bertrand tells me that in the second line this should work as well:
>>>> if(currentNode.getNodes()[i].approved (...)
>>>> It does not give an exception but the property is undefined.
>>>>
>>>
>>
>> --
>> Lars Trieloff
>> lars@trieloff.net
>> http://weblogs.goshaky.com/weblogs/lars
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Lars,
Am Freitag, den 14.03.2008, 10:07 +0100 schrieb Lars Trieloff:
> Hi Felix,
>
> I just had a look at the implementation of ScriptableItemMap and the
> implementation is quite elegant, performance-wise, there are only two
> minor issues:
> - it does not expose the Iterator interface
> - returned items are not casted into scriptablenode and
> scriptableproperty if possible.
The performance issue comes from the constructor which walks along the
iterator upfront. The goal of an iterator is, that we do not have to
walk it upfront.
Of course, the script example provided in SLING-328 is also problematic
as it causes the constructor to be called on each loop iteration causing
the child node iterator to be walked n^2 times (n is the number of child
nodes)....
>
> these two things are quite easy to fix which would allow using the API
> in a spec-conformant way and in a way that can be used with Javascript
> for loops, etc.
As I alwas say: I am ok with supporting JavaScript syntax but I am not
ok with adding more API, which does not exist elsewhere. This will just
create issues.... Therefore, I am really for removing this
functionality.
Regards
Felix
>
> regards,
>
> Lars
>
> On 14.03.2008, at 08:31, Felix Meschberger wrote:
>
> > Hi all,
> >
> > This issue and SLING-329 give raise to an interesting question: The
> > ScriptableNode implements the ECMA getNodes() method returning an EMCA
> > object containing all properties. This is fundamentally different from
> > the spec which says an Iterator is returned.
> >
> > In fact, it completely breaks my knowledge of JCR in that I would
> > not be
> > able to iterate as I would expect it: while (iter.hasNext()) { Node
> > n =
> > iter.next(); }
> >
> > In addition, this might also be a performance hog because the
> > constructor of the respective object iterates the complete JCR
> > iterator
> > to build the object (this is probably required for the
> > implementation).
> >
> > So what are the opinions out there on this break in API ?
> >
> > Regards
> > Felix
> >
> >
> > Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
> > (JIRA):
> >> access to node props in esp
> >> ---------------------------
> >>
> >> Key: SLING-328
> >> URL: https://issues.apache.org/jira/browse/SLING-328
> >> Project: Sling
> >> Issue Type: Bug
> >> Reporter: Michael Marth
> >>
> >>
> >> My .esp looks like
> >>
> >> for (var i in currentNode.getNodes()) {
> >> if(currentNode.getNodes()
> >> [i].getProperty("approved").getString() == "true") {
> >> ...
> >>
> >> Bertrand tells me that in the second line this should work as well:
> >> if(currentNode.getNodes()[i].approved (...)
> >> It does not give an exception but the property is undefined.
> >>
> >
>
> --
> Lars Trieloff
> lars@trieloff.net
> http://weblogs.goshaky.com/weblogs/lars
>
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Lars Trieloff <la...@trieloff.net>.
Hi Felix,
I just had a look at the implementation of ScriptableItemMap and the
implementation is quite elegant, performance-wise, there are only two
minor issues:
- it does not expose the Iterator interface
- returned items are not casted into scriptablenode and
scriptableproperty if possible.
these two things are quite easy to fix which would allow using the API
in a spec-conformant way and in a way that can be used with Javascript
for loops, etc.
regards,
Lars
On 14.03.2008, at 08:31, Felix Meschberger wrote:
> Hi all,
>
> This issue and SLING-329 give raise to an interesting question: The
> ScriptableNode implements the ECMA getNodes() method returning an EMCA
> object containing all properties. This is fundamentally different from
> the spec which says an Iterator is returned.
>
> In fact, it completely breaks my knowledge of JCR in that I would
> not be
> able to iterate as I would expect it: while (iter.hasNext()) { Node
> n =
> iter.next(); }
>
> In addition, this might also be a performance hog because the
> constructor of the respective object iterates the complete JCR
> iterator
> to build the object (this is probably required for the
> implementation).
>
> So what are the opinions out there on this break in API ?
>
> Regards
> Felix
>
>
> Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth
> (JIRA):
>> access to node props in esp
>> ---------------------------
>>
>> Key: SLING-328
>> URL: https://issues.apache.org/jira/browse/SLING-328
>> Project: Sling
>> Issue Type: Bug
>> Reporter: Michael Marth
>>
>>
>> My .esp looks like
>>
>> for (var i in currentNode.getNodes()) {
>> if(currentNode.getNodes()
>> [i].getProperty("approved").getString() == "true") {
>> ...
>>
>> Bertrand tells me that in the second line this should work as well:
>> if(currentNode.getNodes()[i].approved (...)
>> It does not give an exception but the property is undefined.
>>
>
--
Lars Trieloff
lars@trieloff.net
http://weblogs.goshaky.com/weblogs/lars
Re: [jira] Created: (SLING-328) access to node props in esp
Posted by Felix Meschberger <fm...@gmail.com>.
Hi all,
This issue and SLING-329 give raise to an interesting question: The
ScriptableNode implements the ECMA getNodes() method returning an EMCA
object containing all properties. This is fundamentally different from
the spec which says an Iterator is returned.
In fact, it completely breaks my knowledge of JCR in that I would not be
able to iterate as I would expect it: while (iter.hasNext()) { Node n =
iter.next(); }
In addition, this might also be a performance hog because the
constructor of the respective object iterates the complete JCR iterator
to build the object (this is probably required for the implementation).
So what are the opinions out there on this break in API ?
Regards
Felix
Am Donnerstag, den 13.03.2008, 09:40 -0700 schrieb Michael Marth (JIRA):
> access to node props in esp
> ---------------------------
>
> Key: SLING-328
> URL: https://issues.apache.org/jira/browse/SLING-328
> Project: Sling
> Issue Type: Bug
> Reporter: Michael Marth
>
>
> My .esp looks like
>
> for (var i in currentNode.getNodes()) {
> if(currentNode.getNodes()[i].getProperty("approved").getString() == "true") {
> ...
>
> Bertrand tells me that in the second line this should work as well:
> if(currentNode.getNodes()[i].approved (...)
> It does not give an exception but the property is undefined.
>
[jira] Updated: (SLING-328) access to node props in esp
Posted by "Carsten Ziegeler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Carsten Ziegeler updated SLING-328:
-----------------------------------
Component/s: Scripting
> access to node props in esp
> ---------------------------
>
> Key: SLING-328
> URL: https://issues.apache.org/jira/browse/SLING-328
> Project: Sling
> Issue Type: Bug
> Components: Scripting
> Reporter: Michael Marth
>
> My .esp looks like
> for (var i in currentNode.getNodes()) {
> if(currentNode.getNodes()[i].getProperty("approved").getString() == "true") {
> ...
> Bertrand tells me that in the second line this should work as well:
> if(currentNode.getNodes()[i].approved (...)
> It does not give an exception but the property is undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-328) access to node props in esp
Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger updated SLING-328:
------------------------------------
Component/s: (was: Scripting)
Scripting JavaScript (Rhino)
Affects Version/s: Scripting JavaScript 2.0.2
> access to node props in esp
> ---------------------------
>
> Key: SLING-328
> URL: https://issues.apache.org/jira/browse/SLING-328
> Project: Sling
> Issue Type: Bug
> Components: Scripting JavaScript (Rhino)
> Affects Versions: Scripting JavaScript 2.0.2
> Reporter: Michael Marth
>
> My .esp looks like
> for (var i in currentNode.getNodes()) {
> if(currentNode.getNodes()[i].getProperty("approved").getString() == "true") {
> ...
> Bertrand tells me that in the second line this should work as well:
> if(currentNode.getNodes()[i].approved (...)
> It does not give an exception but the property is undefined.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.