> I *do not* love the idea of having to build a bundle every time a script
> changes (if the above is true). This is a non-starter for front-end
> developers... the primary people writing HTL files.

Completely agree with that Chris, we just got to a stage that we can get the 
frontend developers easily involved. 
- Create HTML files 
- Use for example Adobe Brackets or other sync tools to get those files into 
Sling / AEM

I also see that it says "scripts can be overlaid freely through the search path 
override or through the special sling:resourceSuperType property, complicating 
a developer's understanding of the script resolution mechanism". Why is this a 
bad this thing? I think this is one of the strong features of Sling. Making for 
example a base-page and then using resourceSuperType to make all the more 
specific pages through overlaying some specific HTL files.


> On 26 Apr 2018, at 19:26, Chris Millar <cmil...@apache.org> wrote:
> 
> Am I missing something, or will this require a Java build and install every
> time an HTL file is changed?
> 
> I *love* the idea of finally having a real solution to versioning scripts.
> 
> I *love* the idea of not worrying about getting overlaid.
> 
> I *do not* love the idea of having to build a bundle every time a script
> changes (if the above is true). This is a non-starter for front-end
> developers... the primary people writing HTL files.
> 
> While it's been mentioned several times this is an opt-in feature, I can
> see a scenario where Adobe adopts this model (via Core Components) and
> their customers start thinking this is best practice without understanding
> the development tooling hit they will take. Again, this is assuming what I
> said is true. I think this would be bad for the Apache Sling community.
> 
> Now, if sling-ide-tooling moves to be CLI (which I think is underway?),
> this might be a non-issue. But with the above, and not good tooling around
> it, we would be moving away from "save and refresh" dev pipelines. It would
> be, "save, build, install, wait for bundle restart, refresh."
> 
> On Thu, Apr 26, 2018 at 9:33 AM, Radu Cotescu <r...@apache.org> wrote:
> 
>> Hi Jason,
>> 
>>> On 26 Apr 2018, at 17:12, Jason E Bailey <j...@apache.org> wrote:
>>> 
>>> That ability to overlay scripts and the ability to modify or correct a
>> third party implementation is something I use more then I should.
>>> 
>>> Saying that, from my initial look through it looks like I would still be
>> able to overlay, it just wouldn't necessarily be as straightforward as the
>> previous method.
>> 
>> You are right - overlaying wouldn’t work. By overlay we understand placing
>> a script in a search path with a higher priority. I personally find
>> overlaying a questionable technique, since you have the potential of
>> breaking all the other consumers of the overlaid resource type without even
>> knowing.
>> 
>> However, you now have a very powerful extension mechanism - see item 5
>> from the definition of a “sling.resourceType” capability [2]. With this
>> mechanism you know at deploy time if your extension actually works since
>> the framework will start your scripting bundle only if all of its
>> requirements are met. In this case, a resource type you extend is a
>> required capability, whereas your new resource type is a provided
>> capability. With the traditional scripting model (scripts deployed in the
>> repository in the search paths) you’d have to wait until run time to figure
>> out if your extension worked or not. Extends is similar to
>> “sling:resourceSuperType”. See an example at [3].
>> 
>> Cheers,
>> Radu
>> 
>> [2] - https://github.com/apache/sling-whiteboard/tree/master/
>> scripting-resolver/org-apache-sling-scripting-resolver#how <
>> https://github.com/apache/sling-whiteboard/tree/master/
>> scripting-resolver/org-apache-sling-scripting-resolver#how>
>> [3] - https://github.com/apache/sling-whiteboard/blob/master/
>> scripting-resolver/examples/org-apache-sling-scripting-
>> examplebundle.hi/src/main/resources/javax.script/org.
>> apache.sling.scripting.examplebundle.hi/1.0.0/extends <
>> https://github.com/apache/sling-whiteboard/blob/master/
>> scripting-resolver/examples/org-apache-sling-scripting-
>> examplebundle.hi/src/main/resources/javax.script/org.
>> apache.sling.scripting.examplebundle.hi/1.0.0/extends>

Reply via email to