Hi Radu Thanks for starting this thread.
As I wrote in my other message [1], the ScriptEngine management is currently laid out to have script engines to use disjoint extensions. Having two engines with the same extension is not supported. I also don’t really like to have multiple engines to have the same extension. And using „html“ as the extension of a script really is prone for such collisions. Also I don’t like this path thing because it is very brittle and we have enough troubles with them in the Servlet Resolver already … Lets see how Unix' exec() system call does it: It actually ignores the extension and looks for a magic file pattern at the beginning of the file „#!“. So we could extend our ScriptResolution as well like this. If the file begins with a line of the form #!<engine-name><CR><LF> then the named script engine is selected by its name, which now is considered to be unique. The selection only looks at the first two characters to decide whether to actually read the first line. If the first line is of this form, it is consumed and the script engine will not be able to read it — this way we also prevent script engines from failing due to incorrect commenting. If a script does not start with „#!“ then the regular selection by extension kicks in. WDYT ? Regards Felix > Am 23.01.2015 um 11:17 schrieb Radu Cotescu <r...@apache.org>: > > Hello, > > In SLING-4330 [0] Oliver suggests that Sightly should be configured to > render templates only from some search paths sub-paths, because he'd also > like to write some Thymeleaf templates in a project, where the Thymeleaf > script engine also binds itself to the *.html extension. > > However, if we'd like scripting engines to process templates based on > allowed paths I think that this should happen at a higher level. AFAIK a > scripting engine registers itself for an extension, but that's about it. > The behaviour that determines which script engine will provide the > rendering for a resource is implemented by the SlingServletResolver, which > adapts the component's resource to a ScriptEngine. > > The AdapterFactory that performs the adaptation is implemented by > SlingScriptAdapterFactory, which picks the scripting engine based solely on > extension. If we'd change the ScriptEngineFactories to also provide the > path patterns for which they register and we'd expose the patterns as a > configurable OSGi property I think we'd reach the goal of having scripting > engines render templates also based on paths. > > WDYT? > > Regards, > Radu > > [0] - https://issues.apache.org/jira/browse/SLING-4330
