Hi Daniel, Glad to get your feedback on this DL as you're getting started with Sightly! :)
I just wanted to add one small clarification to what Radu said concerning your point 2 (Casting): The Sightly == operator works like the JavaScript == operator, but with the limitation of only accepting variables of the same type. This means that the Sightly == operator corresponds to the common behavior of the JS == and === operators, and where they differ, it currently throws an error. This is the safest to make sure users don't start messing around with types, while staying as close as possible to the JS spec. Best, Gabriel On 08/10/14 16:21, "Daniel Klco" <dk...@apache.org> wrote: >Hi Radu, > >I have been metaphorically kicking the tires of Sightly over the last few >days and have a few questions / concerns. > >1. Performance: > >I found JSP to be roughly 10x faster in contrived tests than Sightly. >I've >uploaded a package which can be run on an AEM6 instance showing the >performance difference between the JSP and Sightly text components here: >https://www.danklco.com/assets/Sightly%20Performance%20Test.zip > >2. Casting: > >It's somewhat concerning to me that we don't see more examples of how >casting works here. What about Dates? Longs? How would a byte[] be >handled? Additionally, the handling of booleans is very concerning. >Complicated value coersion rules for boolean logic is one of the worst >things in JavaScript in my opinion. At the very least there should be the >equivalent of === > >3. Extension: > >Is there an API for adding new statements or options to Sightly? I didn't >see this in the spec. > >4. Sling Integration: > >First, I'd echo the concerns of others that if this is going to be a >general-use language, Sling specific integrations should be part of a >separate integration package. Also, is there an equivalent of the Sling >Resource Access tags in Sightly? What I see this being useful for is basic >display logic where some of the properties may not be on the current >Resource. For example if you have a structure to represent a carousel >like >this: > >... > /carousel > /carousel-item-0 > /carousel-item-1 > /carousel-item-2 > >Would it be possible to loop through the carousel-item child resources and >access their properties? I think the case could be made for creating >separate components or having some external logic be executed, I was just >wondering if this would be possible. > >Thanks, >Dan > > >On Mon, Oct 6, 2014 at 7:46 AM, Radu Cotescu <r...@cotescu.com> wrote: > >> Hi, >> >> You are right. It leaks implementation details which have not been >> abstracted enough. I've reformatted that section to provide a more >>generic >> description for Use-API objects. >> >> Thanks for your feedback! >> >> Regards, >> Radu >> >> On Mon, Oct 6, 2014 at 2:00 PM, Carsten Ziegeler <cziege...@apache.org> >> wrote: >> >> > Thanks Radu, >> > >> > I think it's strange that the spec defines something in the Apache >>Sling >> > namespace (Java Use-API). A spec defined outside of Apache should not >> > define anything in an Apache space. In addition I think for a general >> > purpose templating language this isn't appropriate anyway. >> > >> > Carsten >> > >> > 2014-10-06 12:43 GMT+02:00 Radu Cotescu <r...@apache.org>: >> > >> > > Hello Carsten, >> > > >> > > The official Sightly specification has been published at [2]. The >>TCK >> > > should be ready by the end of next week. >> > > >> > > Regards, >> > > Radu >> > > >> > > [2] - https://github.com/Adobe-Marketing-Cloud/sightly-spec >> > > >> > > On Tue, Sep 23, 2014 at 8:07 AM, Carsten Ziegeler < >> cziege...@apache.org> >> > > wrote: >> > > >> > > > thanks for the offering. This definitely looks very interesting >>for >> > > Sling. >> > > > Is the spec downloadable from somewhere? When do you think the >>test >> > suite >> > > > will be available? >> > > > >> > > >> > >> > >> > >> > -- >> > Carsten Ziegeler >> > Adobe Research Switzerland >> > cziege...@apache.org >> > >>
