You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by lancedolan <la...@gmail.com> on 2017/01/11 01:29:59 UTC
JS Use API usability or limitations
I've got years of experience writing backing beans for Sling (aem)
components, but can't seem to get a simple JS backing working using the new
Javascript Use API.
All I want to do is print out a resource's children resources.
My JS backing bean:
use([], function () {
var returnObj = {
content: ""
};
var parent = resource.parent;
var children = parent.getChildren();
for (res in Iterator(children)) {
returnObj.content += res.name;
}
return returnObj;
});
The contents of returnObj.content will be the word "undefined" repeated X
times, where X is the number of children nodes of parent. This tells me it
successfully iterates the Iterable once for each item in it, but it's
failing to give me a reference to a child. If I try res.getName() instead, I
get:
org.mozilla.javascript.EcmaError: TypeError: Cannot find default value for
object
In fact, every single variation I've tried for iterating that collection has
lead to that exact Exception.
It seems to me Rhino is getting in the way. Am I right? What is the
community consensus on use of the JS Use API? Is it production-ready and
stable? Is my problem a user-error? What limitations exist here? I was
planning on doing the same things in JS that I've always done in Java, which
is usually a lot of read/write operations on the JCR.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: JS Use API usability or limitations
Posted by Vlad Bailescu <vl...@bailescu.ro>.
Hi Lance!
The problem is not the JS Use API but the way the JS Iterator is used. One
should do:
for (var [key, res] in Iterator(children)) {
returnObj.content += res.name;
}
Also, Robert is right, you should strive to keep your business logic (use
objects) as light as possible do the iterating and rendering in the HTL
script, if possible.
Best,
Vlad
On Wed, Jan 11, 2017 at 1:00 PM, Robert Munteanu <ro...@apache.org> wrote:
> Hi,
>
> On Tue, 2017-01-10 at 18:29 -0700, lancedolan wrote:
> > All I want to do is print out a resource's children resources.
>
> Using the HTL repl [1] I narrowed down the following way of listing
> child resources:
>
> template.html
> -------------
>
> <html>
> <head>
> <title>${properties.jcr:title}</title>
> <meta charset="utf-8">
> </head>
> <body data-sly-use.obj="logic.js">
>
> <p>My siblings are:
> <ul data-sly-list.child="${obj.siblings}">
> <li>${child.name}</li>
> </ul>
> </p>
>
> </body>
> </html>
>
> logic.js
> --------
>
> use(function () {
> return {
> siblings: resource.getParent().getChildren()
> };
> });
>
> I don't know enough about the HTL Javascript Use API to see what is
> wrong in your particular example unfortunately.
>
> Robert
>
>
> [1]: http://localhost:8080/htl/repl.html
>
Re: JS Use API usability or limitations
Posted by Robert Munteanu <ro...@apache.org>.
Hi,
On Tue, 2017-01-10 at 18:29 -0700, lancedolan wrote:
> All I want to do is print out a resource's children resources.
Using the HTL repl [1] I narrowed down the following way of listing
child resources:
template.html
-------------
<html>
<head>
����<title>${properties.jcr:title}</title>
����<meta charset="utf-8">
</head>
<body data-sly-use.obj="logic.js">
����<p>My siblings are:
��������<ul data-sly-list.child="${obj.siblings}">
������������<li>${child.name}</li>
��������</ul>
����</p>
</body>
</html>
logic.js
--------
use(function () {
����return {
��������siblings: resource.getParent().getChildren()
����};
});
I don't know enough about the HTL Javascript Use API to see what is
wrong in your particular example unfortunately.
Robert
[1]: http://localhost:8080/htl/repl.html
Re: JS Use API usability or limitations
Posted by Vlad Bailescu <vl...@bailescu.ro>.
Hi
Regarding syntax, I'm not very good at JS and had to peek at
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator.
I understood that this syntax is standard for..in usage (when not using
keyOnly Iterator constructor) and tested it quickly in REPL.
The JS API is as solid (and slow) as Rhino is but debugging is indeed hard.
Best,
Vlad
On Wed, 11 Jan 2017 at 21:37, lancedolan <la...@gmail.com> wrote:
> Thank you for your time everybody! For posterity:
>
>
>
> First to clarify, my very specific question is how to iterate an iterable
> in
>
> the model-building logic (what us old timers might call a "backing bean").
> I
>
> do already know that I can use HTL to iterate the children, and I do
>
> recognize that in this contrived example it's a better separation of
>
> view/model concerns to do so. However I'm going to need to do lots of
>
> iterating on resources in my "backing beans" as I build model data for
>
> increasingly complex objects. Imagine a component that searches various
>
> parts of the JCR and filters on specific properties to generate a
>
> heterogenous list of content links... To suggest HTL just skirts around my
>
> development need in model-building logic.
>
>
>
> Vlad's syntax solved my problem. I'd love to understand why. It seems the
>
> Iterable contains a Map or List objects with a key and resource... Is that
>
> due to Rhino? The Sling docs say getChildren returns Iterable<Resource>. I
>
> didn't expect this.
>
>
>
> I'm already feeling the pain of debugging JS Use API, which Stefan has
>
> warned about, and so did the sling docs on.
>
>
>
> I'm concluding that the JS Use API probably isn't ready and requires too
>
> much esoteric/idiomatic knowledge to give the sort of development speed one
>
> would expect with JS. I'm going to keep it as an option for very simple
>
> components.
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
> View this message in context:
> http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069521.html
>
> Sent from the Sling - Users mailing list archive at Nabble.com.
>
> --
Sent from mobile
RE: JS Use API usability or limitations
Posted by lancedolan <la...@gmail.com>.
Aha. Thanks, I was sure it was sure weird Rhino thing.
It's hard to call it valid JavaScript either, though, as it's invalid in
every single popular browser. That mozilla doc says "Non-standard. The
Iterator function is a SpiderMonkey-specific feature, and will be removed at
some point. " As a career JS developer, I simply wasn't going to know to use
this non-standard and widely unsupported function. On the other hand, using
other modern means, [1] and [2], of iterating the Iterable isn't supported
by Rhino .
I guess my point is just that the same syntax patterns a skilled JavaScript
developer would expect to use aren't always valid, which creates esoteric
knowledge for this environment. Whereas, I felt that all of my existing JS
knowledge was usable when I went to other server-side JS solutions, like
Node.js for example.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069550.html
Sent from the Sling - Users mailing list archive at Nabble.com.
RE: JS Use API usability or limitations
Posted by "Shurmer, Jordan" <js...@scrippsnetworks.com>.
Just to be clear, because it seems like there was a misunderstanding, or at least reading through the thread makes it hard to realize the actual issue here:
The for loop issue wasn't something specific to Rhino, it was just a JS syntax error.
You can see the examples of how to use the Iterator() function on this page:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Iterator
The correct syntax (for JS language, not Rhino specifically) is
for (var [name, value] in Iterator(a)) {
//do the stuff
}
Thanks,
Jordan Shurmer
-----Original Message-----
From: lancedolan [mailto:lance.dolan@gmail.com]
Sent: Wednesday, January 11, 2017 4:42 PM
To: users@sling.apache.org
Subject: RE: JS Use API usability or limitations
No architectural reason - purely speed of development reasons. Our team has switched from Java to Node.js on our other projects and are seeing real gains in dev time. We believe we could see the same faster development with lightweight JS files as opposed to traditional type-safe Java.
I think this is a popular opinion amongst developers, that JS is faster to write in than Java? The question currently on the table is whether the difficulty in debugging esoteric Rhino interactions will negate that speed, in which case we might as well stick to Java and enjoy stability of type safety.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069526.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: JS Use API usability or limitations
Posted by Jason Bailey <Ja...@sas.com>.
I've experienced a variety of results between switching between a dynamic and static types languages I think a lot of it has to do with context.
IMHO there's a certain rhythm to developing on any specific platform. Where using a certain set of technologies make more sense than others. Since everything in Sling is built on Java and you'll be dealing with Java API's, from a business logic perspective, I think you'll get the best results from writing that part In Java. I highly recommend the Sling Models as the starting point for that.
From the view perspective, which I'm using to identify that initial end point service you're calling I don't think it matters as much, although I haven't heard of a lot of people using ecma. I prefer to stick with JSPs since that's what everything boils down to underneath anyways, sticking an abstraction layer over it has always struck me as kind of wasteful.
________________________________________
From: lancedolan <la...@gmail.com>
Sent: Wednesday, January 11, 2017 4:41 PM
To: users@sling.apache.org
Subject: RE: JS Use API usability or limitations
No architectural reason - purely speed of development reasons. Our team has
switched from Java to Node.js on our other projects and are seeing real
gains in dev time. We believe we could see the same faster development with
lightweight JS files as opposed to traditional type-safe Java.
I think this is a popular opinion amongst developers, that JS is faster to
write in than Java? The question currently on the table is whether the
difficulty in debugging esoteric Rhino interactions will negate that speed,
in which case we might as well stick to Java and enjoy stability of type
safety.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069526.html
Sent from the Sling - Users mailing list archive at Nabble.com.
RE: JS Use API usability or limitations
Posted by lancedolan <la...@gmail.com>.
No architectural reason - purely speed of development reasons. Our team has
switched from Java to Node.js on our other projects and are seeing real
gains in dev time. We believe we could see the same faster development with
lightweight JS files as opposed to traditional type-safe Java.
I think this is a popular opinion amongst developers, that JS is faster to
write in than Java? The question currently on the table is whether the
difficulty in debugging esoteric Rhino interactions will negate that speed,
in which case we might as well stick to Java and enjoy stability of type
safety.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069526.html
Sent from the Sling - Users mailing list archive at Nabble.com.
RE: JS Use API usability or limitations
Posted by Jason Bailey <Ja...@sas.com>.
Alright, I'll bite.
If you're talking about model building logic. Is there some architectural constraint on why you don't just stick with java?
-Jason
-----Original Message-----
From: lancedolan [mailto:lance.dolan@gmail.com]
Sent: Wednesday, January 11, 2017 2:37 PM
To: users@sling.apache.org
Subject: RE: JS Use API usability or limitations
Thank you for your time everybody! For posterity:
First to clarify, my very specific question is how to iterate an iterable in the model-building logic (what us old timers might call a "backing bean"). I do already know that I can use HTL to iterate the children, and I do recognize that in this contrived example it's a better separation of view/model concerns to do so. However I'm going to need to do lots of iterating on resources in my "backing beans" as I build model data for increasingly complex objects. Imagine a component that searches various parts of the JCR and filters on specific properties to generate a heterogenous list of content links... To suggest HTL just skirts around my development need in model-building logic.
Vlad's syntax solved my problem. I'd love to understand why. It seems the Iterable contains a Map or List objects with a key and resource... Is that due to Rhino? The Sling docs say getChildren returns Iterable<Resource>. I didn't expect this.
I'm already feeling the pain of debugging JS Use API, which Stefan has warned about, and so did the sling docs on.
I'm concluding that the JS Use API probably isn't ready and requires too much esoteric/idiomatic knowledge to give the sort of development speed one would expect with JS. I'm going to keep it as an option for very simple components.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069521.html
Sent from the Sling - Users mailing list archive at Nabble.com.
RE: JS Use API usability or limitations
Posted by lancedolan <la...@gmail.com>.
Thank you for your time everybody! For posterity:
First to clarify, my very specific question is how to iterate an iterable in
the model-building logic (what us old timers might call a "backing bean"). I
do already know that I can use HTL to iterate the children, and I do
recognize that in this contrived example it's a better separation of
view/model concerns to do so. However I'm going to need to do lots of
iterating on resources in my "backing beans" as I build model data for
increasingly complex objects. Imagine a component that searches various
parts of the JCR and filters on specific properties to generate a
heterogenous list of content links... To suggest HTL just skirts around my
development need in model-building logic.
Vlad's syntax solved my problem. I'd love to understand why. It seems the
Iterable contains a Map or List objects with a key and resource... Is that
due to Rhino? The Sling docs say getChildren returns Iterable<Resource>. I
didn't expect this.
I'm already feeling the pain of debugging JS Use API, which Stefan has
warned about, and so did the sling docs on.
I'm concluding that the JS Use API probably isn't ready and requires too
much esoteric/idiomatic knowledge to give the sort of development speed one
would expect with JS. I'm going to keep it as an option for very simple
components.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069521.html
Sent from the Sling - Users mailing list archive at Nabble.com.
RE: JS Use API usability or limitations
Posted by Stefan Seifert <ss...@pro-vision.de>.
i've not tested your example but by reading the code i would say it should work like this conceptually.
i think there is no "community consensus" on using the JS use API or not. i personally would advise to not use it for non-trivial tasks, because it creates a unhealthy combination of javascript and java objects within the JS logic with often unexpected results even on simple thinks like string operations because you often do not know exactly if you have a js stirng or a java string object. it's also quite difficult to debug in this cases. my recommendation is to go with sling models and unit tests.
stefan
>-----Original Message-----
>From: lancedolan [mailto:lance.dolan@gmail.com]
>Sent: Wednesday, January 11, 2017 2:30 AM
>To: users@sling.apache.org
>Subject: JS Use API usability or limitations
>
>I've got years of experience writing backing beans for Sling (aem)
>components, but can't seem to get a simple JS backing working using the
>new
>Javascript Use API.
>
>All I want to do is print out a resource's children resources.
>
>My JS backing bean:
>
>use([], function () {
>
> var returnObj = {
> content: ""
> };
>
> var parent = resource.parent;
> var children = parent.getChildren();
>
> for (res in Iterator(children)) {
> returnObj.content += res.name;
> }
>
> return returnObj;
>});
>
>The contents of returnObj.content will be the word "undefined" repeated
>X
>times, where X is the number of children nodes of parent. This tells me
>it
>successfully iterates the Iterable once for each item in it, but it's
>failing to give me a reference to a child. If I try res.getName()
>instead, I
>get:
>
>org.mozilla.javascript.EcmaError: TypeError: Cannot find default value
>for
>object
>
>In fact, every single variation I've tried for iterating that collection
>has
>lead to that exact Exception.
>
>It seems to me Rhino is getting in the way. Am I right? What is the
>community consensus on use of the JS Use API? Is it production-ready and
>stable? Is my problem a user-error? What limitations exist here? I was
>planning on doing the same things in JS that I've always done in Java,
>which
>is usually a lot of read/write operations on the JCR.
>
>
>
>--
>View this message in context: http://apache-
>sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-
>tp4069490.html
>Sent from the Sling - Users mailing list archive at Nabble.com.