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 2015/01/23 11:17:53 UTC
[discussion] allow Script Engines to also render components based on paths
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
Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 23 January 2015 14:03:08 Felix Meschberger wrote:
> Hi
>
>
> > Am 23.01.2015 um 13:29 schrieb Radu Cotescu <ra...@apache.org>:
> >
> > On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz <ap...@oliverlietz.de>
> > wrote:
> >
> >>> Whatever the approach is, if we want to allow multiple scripting
> >>> engines
> >>
> >> to
> >>
> >>> use the same extension we need to refactor the code from the
> >>> SlingScriptEngineManager.
> >>
> >>
> >> Why? The ScriptEngine itself can decide if it kicks in for a script
> >> based
> >> on
> >> the paths patterns.
> >
> >
> >
> >
> > Because currently the script engines are just template processors. The
> > SlingServletResolver is the component that maps a request to the script
> > engine that will provide the output, with the help of the
> > SlingScriptAdapterFactory and the SlingScriptEngineManager.
>
>
> Exactly: The SlingScriptAdapterFactory checks the extension of the script
> and selects the ScriptEngine for this extension. Only one
> ScriptEngineFactory of a particular extension can be registered at any one
> time. So this one is select and called to evaluate the script. If the
> ScriptEngine decides to not actually evaluate it, nothing more happens.
> We have to make sure we improve on the ScriptEngine selection mechanism. I
> don’t want to cycle through multiple ScriptEngine’s until one decides to
> handle….
Ok, that is what I had in mind. Right now Thymeleaf's template resolver
checks if the path of the resource resolved by Sling (as described by Radu)
matches the configured patterns. If it's not the case a default servlet
renders the (HTML) script.
Regards,
O.
> Regards
> Felix
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 23, 2015 at 3:41 PM, Chetan Mehrotra
<ch...@gmail.com> wrote:
> On Fri, Jan 23, 2015 at 7:59 PM, Radu Cotescu <ra...@apache.org> wrote:
>> But we'd need a mixin, as scripts are usually nt:file nodes. Right?
> ...Other way would be to leverage the
> jcr:mimeType on the child jcr:content node which are mostly of type
> nt:resource...
But setting any of those is not convenient when you're editing scripts
via WebDAV for example.
I much prefer the suggestion to set a property higher in tree, so for
example setting
/apps/foo@sling:script = html:thymeleaf.
Causes the html extension to be mapped to the thymeleaf engine for any
script found under there.
That looks efficient, simple to manage, we'd just need to complain
loudly including a pointer to that feature if two script engines are
configured with the same extension and this is not set.
-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Radu Cotescu <ra...@apache.org>.
On Fri, Jan 23, 2015 at 4:41 PM, Chetan Mehrotra <ch...@gmail.com>
wrote:
> Other way would be to leverage the
> jcr:mimeType on the child jcr:content node which are mostly of type
> nt:resource.
>
text/thymeleaf, text/sightly, text/jsp...? :)
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Fri, Jan 23, 2015 at 7:59 PM, Radu Cotescu <ra...@apache.org> wrote:
> But we'd need a mixin, as scripts are usually nt:file nodes. Right?
That is one possible way. Other way would be to leverage the
jcr:mimeType on the child jcr:content node which are mostly of type
nt:resource. Typically a script has a backing mimeType [2]
Chetan Mehrotra
[1] http://wiki.apache.org/jackrabbit/nt%3Afile
[2] http://docs.oracle.com/javase/7/docs/api/javax/script/ScriptEngineFactory.html#getMimeTypes()
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Radu Cotescu <ra...@apache.org>.
On Fri, Jan 23, 2015 at 4:21 PM, Chetan Mehrotra <ch...@gmail.com>
wrote:
> +1. This looks more safer and less disrupting as reading the property
> is cheaper.
>
But we'd need a mixin, as scripts are usually nt:file nodes. Right?
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Fri, Jan 23, 2015 at 7:45 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> What about adding an additional property to the script resource?
+1. This looks more safer and less disrupting as reading the property
is cheaper.
The script header approach looks nice but would require changes at
quite a few places
Chetan Mehrotra
Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Monday 26 January 2015 09:39:09 Jeff Young wrote:
> I'm in agreement with Justin and Bertrand that the developer (and not the
> administrator) is the right person to author this information.
When a team delivers a slightly more ambitious application an admin has to
kick in anyway, e.g. to configure service user mapping, security, URL mappings
or the like.
Configuring the script engines is an admin task in my opinion also (and could
be therefore more restrictive).
I've updated the issue with our findings so far.
Regards,
O.
> I'm on the fence regarding whether to put it in the file or use a
> property. (If we do use a property, it should be inherited so it can be
> put on entire sub-trees easily.)
>
> Cheers,
> Jeff.
>
> On 26/01/2015 09:24, "Bertrand Delacretaz" <bd...@apache.org> wrote:
> >On Sat, Jan 24, 2015 at 12:34 PM, Justin Edelson
> >
> ><ju...@justinedelson.com> wrote:
> >> ...Only the developer knows how to map their scripts to the right
> >>
> >>engine....
> >
> >And the developer creates scripts under /apps/foo for project foo, so
> >it makes absolute sense to set a sling:script property on /apps/foo to
> >indicate a preference for one script engine over another under there.
> >
> >-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Alexander Klimetschek <ak...@adobe.com>.
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 <fm...@adobe.com> wrote:
>
> Hi
>
>> Am 26.01.2015 um 11:29 schrieb Bertrand Delacretaz <bd...@apache.org>:
>>
>> On Mon, Jan 26, 2015 at 11:25 AM, Felix Meschberger <fm...@adobe.com> 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
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
> Am 26.01.2015 um 11:29 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
> On Mon, Jan 26, 2015 at 11:25 AM, Felix Meschberger <fm...@adobe.com> 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
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jan 26, 2015 at 11:25 AM, Felix Meschberger <fm...@adobe.com> 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?
I like it - we just need to make sure to properly log + inform the
RequestProgressTracker of what's happening, to make it transparent.
-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
> Am 26.01.2015 um 11:03 schrieb Bertrand Delacretaz <bd...@apache.org>:
>
> On Mon, Jan 26, 2015 at 10:39 AM, Jeff Young <je...@adobe.com> wrote:
>> ...If we do use a property, it should be inherited so it can be
>> put on entire sub-trees easily...
>
> Yes that's my idea, just put sling:script=thymeleaf on /apps/foo to
> indicate that thymeleaf is the preferred engine for scripts found
> anywhere under /apps/foo, in case multiple engines are mapped to the
> same script extension.
Maybe we should add somewhat more to be able to declare a mapping from extension to concrete script language name, which in turn must exactly match what the Script Engine declares, e.g.
sling:script = [
„html=thymeleaf“,
„js=nashorn“
]
So the property is (optionally) multi-value and consists of a a string describing a name-value pair to map the script file extension to the language name. The adapter factory can then consider the script resource, the extension, this mapping and quickly find the appropriate engine.
Since I would not expect that many sling:script properties all over places, I would think we could run a simple query on startup to gather the properties and then register an event listener to get informed of updates ...
Regards
Felix
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Jan 26, 2015 at 10:39 AM, Jeff Young <je...@adobe.com> wrote:
>...If we do use a property, it should be inherited so it can be
> put on entire sub-trees easily...
Yes that's my idea, just put sling:script=thymeleaf on /apps/foo to
indicate that thymeleaf is the preferred engine for scripts found
anywhere under /apps/foo, in case multiple engines are mapped to the
same script extension.
-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Jeff Young <je...@adobe.com>.
I'm in agreement with Justin and Bertrand that the developer (and not the
administrator) is the right person to author this information.
I'm on the fence regarding whether to put it in the file or use a
property. (If we do use a property, it should be inherited so it can be
put on entire sub-trees easily.)
Cheers,
Jeff.
On 26/01/2015 09:24, "Bertrand Delacretaz" <bd...@apache.org> wrote:
>On Sat, Jan 24, 2015 at 12:34 PM, Justin Edelson
><ju...@justinedelson.com> wrote:
>> ...Only the developer knows how to map their scripts to the right
>>engine....
>
>And the developer creates scripts under /apps/foo for project foo, so
>it makes absolute sense to set a sling:script property on /apps/foo to
>indicate a preference for one script engine over another under there.
>
>-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sat, Jan 24, 2015 at 12:34 PM, Justin Edelson
<ju...@justinedelson.com> wrote:
> ...Only the developer knows how to map their scripts to the right engine....
And the developer creates scripts under /apps/foo for project foo, so
it makes absolute sense to set a sling:script property on /apps/foo to
indicate a preference for one script engine over another under there.
-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
On Saturday, January 24, 2015, Oliver Lietz <ap...@oliverlietz.de> wrote:
> On Friday 23 January 2015 15:42:46 Gabriel Walt wrote:
> > Hi,
> >
> > Isn't it possible to have some form of configuration that allows to
> > register scripting languages based on paths when needed?
> >
> > E.g. by default we could following config:
> > *.jsp => JSP engine
> > *.html => Thymeleaf engine
> >
> > And then by path we could override:
> > *.html in /foo => Sightly engine
> >
> > It would be great if only the default values would be global, and one can
> > apply something like mixin to the /foo path to make everything below it
> to
> > use Sightly instead of Thymeleaf.
> >
> > I doubt that many projects will mix different HTML template languages to
> a
> > point where we need to control it on a file level. The reason I'd like to
> > avoid this is that it would make it a pain when serializing/synchronizing
> > the repository content to a file system, as it would create an additional
> > folder structure for each file-level mixin or jcr:mimeType. This
> structure
> > would then have to be manually created for each newly created template
> > file... I have the impression that not allowing to mix different HTML
> > template languages within the same folder would be an acceptable
> > limitation.
>
> +1
>
> > I also would like to avoid to have a marker in the template to identify
> > the script engine to use, as it would mess with the HTML/XML validity,
> > having to read the 200 chars, which can be confusing if the marker
> doesn't
> > have to be (and sometimes really shouldn't be) on the first line.
>
> +1
>
> I still think that configuring the paths patterns to select a script
> engine is
> the way to go.
The problem I see with this is that the administrator (who is responsible
for this configuration) isn't the best one to know how to configure this...
Only the developer knows how to map their scripts to the right engine.
Regards,
Justin
>
> Regards,
> O.
>
> >
> > Best,
> > Gabriel
>
>
Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 23 January 2015 15:42:46 Gabriel Walt wrote:
> Hi,
>
> Isn't it possible to have some form of configuration that allows to
> register scripting languages based on paths when needed?
>
> E.g. by default we could following config:
> *.jsp => JSP engine
> *.html => Thymeleaf engine
>
> And then by path we could override:
> *.html in /foo => Sightly engine
>
> It would be great if only the default values would be global, and one can
> apply something like mixin to the /foo path to make everything below it to
> use Sightly instead of Thymeleaf.
>
> I doubt that many projects will mix different HTML template languages to a
> point where we need to control it on a file level. The reason I'd like to
> avoid this is that it would make it a pain when serializing/synchronizing
> the repository content to a file system, as it would create an additional
> folder structure for each file-level mixin or jcr:mimeType. This structure
> would then have to be manually created for each newly created template
> file... I have the impression that not allowing to mix different HTML
> template languages within the same folder would be an acceptable
> limitation.
+1
> I also would like to avoid to have a marker in the template to identify
> the script engine to use, as it would mess with the HTML/XML validity,
> having to read the 200 chars, which can be confusing if the marker doesn't
> have to be (and sometimes really shouldn't be) on the first line.
+1
I still think that configuring the paths patterns to select a script engine is
the way to go.
Regards,
O.
>
> Best,
> Gabriel
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Gabriel Walt <gw...@adobe.com>.
Hi,
Isn't it possible to have some form of configuration that allows to
register scripting languages based on paths when needed?
E.g. by default we could following config:
*.jsp => JSP engine
*.html => Thymeleaf engine
And then by path we could override:
*.html in /foo => Sightly engine
It would be great if only the default values would be global, and one can
apply something like mixin to the /foo path to make everything below it to
use Sightly instead of Thymeleaf.
I doubt that many projects will mix different HTML template languages to a
point where we need to control it on a file level. The reason I'd like to
avoid this is that it would make it a pain when serializing/synchronizing
the repository content to a file system, as it would create an additional
folder structure for each file-level mixin or jcr:mimeType. This structure
would then have to be manually created for each newly created template
file... I have the impression that not allowing to mix different HTML
template languages within the same folder would be an acceptable
limitation.
I also would like to avoid to have a marker in the template to identify
the script engine to use, as it would mess with the HTML/XML validity,
having to read the 200 chars, which can be confusing if the marker doesn't
have to be (and sometimes really shouldn't be) on the first line.
Best,
Gabriel
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Justin Edelson <ju...@justinedelson.com>.
FWIW, I think it would be more natural to set this on the container
node, so if you have /apps/foo/bar/something.html, I'd set
/apps/foo/bar@sling:script = html:thymeleaf.
We could, however, support both per-script and per-container settings,
but I don't think it is necessary to go more than one level up.
Regards,
Justin
On Fri, Jan 23, 2015 at 9:18 AM, Felix Meschberger <fm...@adobe.com> wrote:
> Reminds me of the Mac Resource Forks … :-)
>
> It would be neat to be able to set this in/on the script itself without having to manage some out-of-band metadata.
>
> Regards
> Felix
>
>> Am 23.01.2015 um 15:15 schrieb Carsten Ziegeler <cz...@apache.org>:
>>
>> What about adding an additional property to the script resource?
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziegeler@apache.org
>
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Felix Meschberger <fm...@adobe.com>.
Reminds me of the Mac Resource Forks … :-)
It would be neat to be able to set this in/on the script itself without having to manage some out-of-band metadata.
Regards
Felix
> Am 23.01.2015 um 15:15 schrieb Carsten Ziegeler <cz...@apache.org>:
>
> What about adding an additional property to the script resource?
>
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziegeler@apache.org
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Carsten Ziegeler <cz...@apache.org>.
What about adding an additional property to the script resource?
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
> Am 23.01.2015 um 13:29 schrieb Radu Cotescu <ra...@apache.org>:
>
> On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz <ap...@oliverlietz.de> wrote:
>
>>> Whatever the approach is, if we want to allow multiple scripting engines
>> to
>>> use the same extension we need to refactor the code from the
>>> SlingScriptEngineManager.
>>
>> Why? The ScriptEngine itself can decide if it kicks in for a script based
>> on
>> the paths patterns.
>
>
>
> Because currently the script engines are just template processors. The
> SlingServletResolver is the component that maps a request to the script
> engine that will provide the output, with the help of the
> SlingScriptAdapterFactory and the SlingScriptEngineManager.
Exactly: The SlingScriptAdapterFactory checks the extension of the script and selects the ScriptEngine for this extension. Only one ScriptEngineFactory of a particular extension can be registered at any one time. So this one is select and called to evaluate the script. If the ScriptEngine decides to not actually evaluate it, nothing more happens.
We have to make sure we improve on the ScriptEngine selection mechanism. I don’t want to cycle through multiple ScriptEngine’s until one decides to handle….
Regards
Felix
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Radu Cotescu <ra...@apache.org>.
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> > Whatever the approach is, if we want to allow multiple scripting engines
> to
> > use the same extension we need to refactor the code from the
> > SlingScriptEngineManager.
>
> Why? The ScriptEngine itself can decide if it kicks in for a script based
> on
> the paths patterns.
Because currently the script engines are just template processors. The
SlingServletResolver is the component that maps a request to the script
engine that will provide the output, with the help of the
SlingScriptAdapterFactory and the SlingScriptEngineManager.
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Radu Cotescu <ra...@apache.org>.
On Fri, Jan 23, 2015 at 2:08 PM, Robert Munteanu <ro...@lmn.ro> wrote:
> If we configure various ScriptEngine implementations it becomes harder
> to get an overview of what it configured where. It's even possible to
> have conflicting patterns in two scripting engines.
>
We could have a master component that provides the needed configuration for
all engines, simplifying the configuration issue you mentioned.
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Robert Munteanu <ro...@lmn.ro>.
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz <ap...@oliverlietz.de> wrote:
>
>> Whatever the approach is, if we want to allow multiple scripting engines to
>> use the same extension we need to refactor the code from the
>> SlingScriptEngineManager.
>
> Why? The ScriptEngine itself can decide if it kicks in for a script based on
> the paths patterns.
If we configure various ScriptEngine implementations it becomes harder
to get an overview of what it configured where. It's even possible to
have conflicting patterns in two scripting engines.
Robert
--
Sent from my (old) computer
Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 23 January 2015 13:33:37 Radu Cotescu wrote:
> On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> > wrote:
> >
> > Good point - we can consider that notation say anywhere in the first
> > 200 chars of the script, so
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!-- sling:language: thymeleaf -->
> > <foo/>
> >
> > would work, the pattern being "sling:language" followed by whitespace
> > and one word which is the language name.
>
> This has the disadvantage that the Servlet Resolver would have to parse the
> first n characters of the script and then the Script Engine would parse
> again the whole file. We should not increase the number of resource reads,
> if not really needed.
>
> If we want to have a conflict resolution mechanism we could add a property
> on component nodes (but they must be sling:Folder / nt:unstructured) that
> would handle which of the multiple scripting engines registered for the
> same extension should be used:
>
> "sling:script" -> "html:thymeleaf"
>
> This would essentially say that for the *.html scripts for this component,
> Thymeleaf should be used.
>
> However, this adds an unnecessary step for component developers. I think
> the configurable patterns on the ScriptEngineFactories is simpler, as this
> is essentially a deployment issue.
Totally agree.
> Whatever the approach is, if we want to allow multiple scripting engines to
> use the same extension we need to refactor the code from the
> SlingScriptEngineManager.
Why? The ScriptEngine itself can decide if it kicks in for a script based on
the paths patterns.
O.
Re: Re: [discussion] allow Script Engines to also render components
based on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 23, 2015 at 12:15 PM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> ... the pattern being "sling:language" followed by whitespace
> and one word which is the language name....
Or maybe "sling:script" to avoid confusion with human languages.
-Bertrand
Re: Re: [discussion] allow Script Engines to also render components
based on paths
Posted by Radu Cotescu <ra...@apache.org>.
On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> Good point - we can consider that notation say anywhere in the first
> 200 chars of the script, so
>
> <?xml version="1.0" encoding="UTF-8"?>
> <!-- sling:language: thymeleaf -->
> <foo/>
>
> would work, the pattern being "sling:language" followed by whitespace
> and one word which is the language name.
>
This has the disadvantage that the Servlet Resolver would have to parse the
first n characters of the script and then the Script Engine would parse
again the whole file. We should not increase the number of resource reads,
if not really needed.
If we want to have a conflict resolution mechanism we could add a property
on component nodes (but they must be sling:Folder / nt:unstructured) that
would handle which of the multiple scripting engines registered for the
same extension should be used:
"sling:script" -> "html:thymeleaf"
This would essentially say that for the *.html scripts for this component,
Thymeleaf should be used.
However, this adds an unnecessary step for component developers. I think
the configurable patterns on the ScriptEngineFactories is simpler, as this
is essentially a deployment issue.
Whatever the approach is, if we want to allow multiple scripting engines to
use the same extension we need to refactor the code from the
SlingScriptEngineManager.
Re: Re: [discussion] allow Script Engines to also render components
based on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 23, 2015 at 11:55 AM, Oliver Lietz <ap...@oliverlietz.de> wrote:
> ...Adding a Shebang to XML and HTML makes them invalid....
Good point - we can consider that notation say anywhere in the first
200 chars of the script, so
<?xml version="1.0" encoding="UTF-8"?>
<!-- sling:language: thymeleaf -->
<foo/>
would work, the pattern being "sling:language" followed by whitespace
and one word which is the language name.
-Bertrand
Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 23 January 2015 06:13:07 Carsten Ziegeler wrote:
> Am 23.01.15 um 06:04 schrieb Felix Meschberger:
> >> Adding a Shebang to XML and HTML makes them invalid. So that won't work.
> >
> > Technically yes, but from a processing perspective no: because the
> > SlingScriptAdapterFactory will it it up and the ScriptEngine should not
> > be able to see it anymore.
> But wouldn't that mean that we potentially loose the tooling advantages
> as the tools might not cope with the extra line at the beginning and
> consider the file invalid?
Exactly.
O.
> Carsten
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Carsten Ziegeler <cz...@apache.org>.
Am 23.01.15 um 06:04 schrieb Felix Meschberger:
>>
>> Adding a Shebang to XML and HTML makes them invalid. So that won't work.
>
> Technically yes, but from a processing perspective no: because the SlingScriptAdapterFactory will it it up and the ScriptEngine should not be able to see it anymore.
>
But wouldn't that mean that we potentially loose the tooling advantages
as the tools might not cope with the extra line at the beginning and
consider the file invalid?
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
> Am 23.01.2015 um 11:55 schrieb Oliver Lietz <ap...@oliverlietz.de>:
>
> On Friday 23 January 2015 10:30:26 Felix Meschberger wrote:
>> 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 ?
>
> Adding a Shebang to XML and HTML makes them invalid. So that won't work.
Technically yes, but from a processing perspective no: because the SlingScriptAdapterFactory will it it up and the ScriptEngine should not be able to see it anymore.
Regards
Felix
>
> Regards,
> O.
>
>> Regards
>> Felix
>>
>>
>>> Am 23.01.2015 um 11:17 schrieb Radu Cotescu <ra...@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
>>
>>
>
Re: Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 23 January 2015 10:30:26 Felix Meschberger wrote:
> 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 ?
Adding a Shebang to XML and HTML makes them invalid. So that won't work.
Regards,
O.
> Regards
> Felix
>
>
> > Am 23.01.2015 um 11:17 schrieb Radu Cotescu <ra...@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
>
>
Re: [discussion] allow Script Engines to also render components based on paths
Posted by Oliver Lietz <ap...@oliverlietz.de>.
On Friday 23 January 2015 11:52:20 Bertrand Delacretaz wrote:
> On Fri, Jan 23, 2015 at 11:30 AM, Felix Meschberger <fm...@adobe.com>
wrote:
> > We could extend our ScriptResolution as well like this. If the file begins
> > with a line of the form>
> > #!<engine-name><CR><LF>
>
> Why not. It's a bit costly as you need to read part of the script
> during resolution but I suppose this can be cached.
>
> I'd make the syntax specific to Sling then, maybe like
>
> #!sling:language thymeleaf
>
> so that people know where to look for the meaning of that.
>
> And of course make the engine's extensions configurable (I hope that's
> already the case) so if someone wants to use .sly for Sightly and .tlf
> for Thymeleaf that should be possible.
That's the case for Thymeleaf.
Thymeleaf 3 comes with support for pure templates - HTML/XML without Thymeleaf
tags/attributes at all - so pure HTML/XML.
O.
> -Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Fri, Jan 23, 2015 at 11:30 AM, Felix Meschberger <fm...@adobe.com> wrote:
> We could extend our ScriptResolution as well like this. If the file begins with a line of the form
>
> #!<engine-name><CR><LF>
Why not. It's a bit costly as you need to read part of the script
during resolution but I suppose this can be cached.
I'd make the syntax specific to Sling then, maybe like
#!sling:language thymeleaf
so that people know where to look for the meaning of that.
And of course make the engine's extensions configurable (I hope that's
already the case) so if someone wants to use .sly for Sightly and .tlf
for Thymeleaf that should be possible.
-Bertrand
Re: [discussion] allow Script Engines to also render components based
on paths
Posted by Felix Meschberger <fm...@adobe.com>.
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 <ra...@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