RE: JS Use API usability or limitations
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
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 <lance.do...@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
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
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.do...@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. 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
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. 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
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 Munteanuwrote: > 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 > - > > > > ${properties.jcr:title} > > > > > My siblings are: > > ${child.name} > > > > > > > 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
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 - ${properties.jcr:title} My siblings are: ${child.name} 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
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.do...@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.