Chiming in late ... Going back to the original issue: Why can't the development team with the conflict handle that?
E.g. if they use a Sling system with some existing scripts that use say sightly with html extension, and now they start to add Thymeleaf stuff, then yes, that's a conflict and they'd rename the Thymleaf files to "tlf" or something and configure the script engine accordingly. All the solutions proposed here don't feel right: - a sling:script property at a root folder: probably expensive to read (always traverse up the ancestry on every script read) and difficult to cache - change jcr:mimeType of script: lost over webdav or other ways to sync with filesystem - shebang: doesn't work easily with all file formats (and most importantly not with the 2 discussed here) Cheers, Alex > On 26.01.2015, at 04:14, Felix Meschberger <[email protected]> wrote: > > Hi > >> Am 26.01.2015 um 11:29 schrieb Bertrand Delacretaz <[email protected]>: >> >> On Mon, Jan 26, 2015 at 11:25 AM, Felix Meschberger <[email protected]> >> wrote: >>> ...Maybe we should add somewhat more to be able to declare a mapping >>> from extension to concrete script language name,... >> >>> sling:script = [ >>> „html=thymeleaf“, >>> „js=nashorn“ >>> ] >> >> Ok, so this would completely override the configured >> extension-to-script engine mappings, for the values of the >> sling:script property? > > Good point ! I think we can use this configured mapping, but if the selected > script engine does not support the extension, the configured mapping should > still be ignored. > > We don’t want things like this: > > sling:script = „html=JSP“ > > to cause a Thymeleaf or Sightly script to be run through the JSP processor > >> >> I like it - we just need to make sure to properly log + inform the >> RequestProgressTracker of what's happening, to make it transparent. > > Excellent point — we just would have to see how this could be done because > the adapter factory might not have access to the RequestProgressTracker. > > Regards > Felix
