sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy Teeuwen <...@teeuwen.be>
Subject Re: [proposal][osgi][scripting] redesigned scripts deployment and resolution
Date Fri, 27 Apr 2018 07:21:47 GMT
> 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 <cmillar@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 <radu@apache.org> wrote:
> 
>> Hi Jason,
>> 
>>> On 26 Apr 2018, at 17:12, Jason E Bailey <jeb@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>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message