You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Radu Cotescu <ra...@apache.org> on 2014/10/06 12:43:13 UTC
Re: [PROPOSAL] Sightly donation to Apache Sling
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 <cz...@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?
>
Re: [PROPOSAL] Sightly donation to Apache Sling
Posted by Radu Cotescu <ra...@apache.org>.
Hello,
I'd like to provide you with an update regarding Sightly as we've just
released the Adobe Sightly TCK [3] (also available on Maven Central).
Two requirements to integrate Sightly into Sling were:
1. have a published language specification [2]
2. provide some tests to validate the implementation donated to Sling; this
is now implemented by integrating [3] into the Sightly build process from
the updated org.apache.sling.scripting.sightly.zip archive from SLING-3959
Thanks,
Radu
[2] - https://github.com/Adobe-Marketing-Cloud/sightly-spec
[3] - https://github.com/Adobe-Marketing-Cloud/sightly-tck
On Fri, Oct 10, 2014 at 11:49 AM, Gabriel Walt <gw...@adobe.com> wrote:
>
> 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 <ra...@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 <cz...@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 <ra...@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 <
> >> cziegeler@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
> >> > cziegeler@apache.org
> >> >
> >>
>
>
Re: [PROPOSAL] Sightly donation to Apache Sling
Posted by Gabriel Walt <gw...@adobe.com>.
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 <ra...@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 <cz...@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 <ra...@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 <
>> cziegeler@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
>> > cziegeler@apache.org
>> >
>>
Re: [PROPOSAL] Sightly donation to Apache Sling
Posted by Radu Cotescu <ra...@apache.org>.
Hi Dan,
Thank you for your feedback! Please check my inline answers below:
On Wed, Oct 8, 2014 at 5:21 PM, Daniel Klco <dk...@apache.org> wrote:
>
> 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
>
The Sightly foundation components from AEM 6.0 use JavaScript Use-API
objects evaluated in Rhino. The Sightly JS Use provider shipped with AEM6.0
suffered from a performance hit due to the fact that Rhino seems to be
slower when compiling JS objects than when evaluating them directly. In 6.0
SP1 JS Use-API objects are evaluated, which greatly reduced rendering time
for components using JS Use-API objects.
On my machine, with SP1, the rendering time ratio is 1:5 in favour of JSPs
with your test (these rendering ratios should more or less be the same,
irrespective of the CPUs we have, right?!). However some performance gains
can be obtained if:
1. the Use-API objects are written in Java
(and / or)
2. you configure the Use providers so that they're evaluated in the order
which will most likely return a success outcome (e.g. if your Use-API
objects are in the JCR repo, then it would make sense for the
PojoUseProvider to run first)
Now, keep in mind that Sightly is designed with the primary goal of
simplifying component development. Obviously, this shouldn't come with a
severe performance cost. But simplified component development means that
components should be easily implemented by web developers, whose knowledge
is more geared towards HTML, CSS and JavaScript. That's one of the reasons
there's a JS Use-API - consider it as an enablement feature for the typical
web developer.
After releasing the TCK I will concentrate my efforts in improving several
areas which could offer us a performance gain without requiring manual
tuning or Use-objects migration. The end-goal is to have a performance
ratio >= 1:2.
>
>
> 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 ===
>
Sightly is not a strongly typed programming language, it's a web templating
language. Since JavaScript is the de-facto scripting language for the web
we decided to implement its coercion rules when it comes to casting to
boolean.
I'll add more examples in the casting section. However, the current
implementation handles casting to Strings for primitives and collections.
For all objects you can call the toString method in your templates.
>
> 3. Extension:
>
> Is there an API for adding new statements or options to Sightly? I didn't
> see this in the spec.
>
Currently we don't support adding new block elements through an API.
Options could be added in any implementation without breaking the spec.
However I don't think the way options are added to expressions should be
part of a specification that aims to be independent of the implementation.
These are more implementation-specific details. I'll make sure to document
these for Sling.
>
> 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.
>
There's no equivalent for Sling Resource Access tags - at the core of a
Sightly script is the resource which was accessed. You could iterate over
child resources and perform some processing in an Use-object, or, like you
suggested, create separate components and include the child resources with
data-sly-include.
I'm really thankful for your constructive reviews. I think most of the
questions will find their answers once we can build a Sling launchpad with
Sightly support.
Thanks,
Radu
Re: [PROPOSAL] Sightly donation to Apache Sling
Posted by Daniel Klco <dk...@apache.org>.
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 <ra...@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 <cz...@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 <ra...@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 <
> cziegeler@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
> > cziegeler@apache.org
> >
>
Re: [PROPOSAL] Sightly donation to Apache Sling
Posted by Radu Cotescu <ra...@cotescu.com>.
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 <cz...@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 <ra...@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 <cz...@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
> cziegeler@apache.org
>
Re: [PROPOSAL] Sightly donation to Apache Sling
Posted by Carsten Ziegeler <cz...@apache.org>.
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 <ra...@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 <cz...@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
cziegeler@apache.org