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
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
On Mon, Jan 26, 2015 at 10:39 AM, Jeff Young j...@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
Hi
Am 26.01.2015 um 11:03 schrieb Bertrand Delacretaz bdelacre...@apache.org:
On Mon, Jan 26, 2015 at 10:39 AM, Jeff Young j...@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
On Mon, Jan 26, 2015 at 11:25 AM, Felix Meschberger fmesc...@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
On Sat, Jan 24, 2015 at 12:34 PM, Justin Edelson
jus...@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
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
Hi
Am 26.01.2015 um 11:29 schrieb Bertrand Delacretaz bdelacre...@apache.org:
On Mon, Jan 26, 2015 at 11:25 AM, Felix Meschberger fmesc...@adobe.com
wrote:
...Maybe we should add somewhat more to be able to declare a mapping
from extension to concrete script language name,...
On Friday 23 January 2015 14:03:08 Felix Meschberger wrote:
Hi
Am 23.01.2015 um 13:29 schrieb Radu Cotescu r...@apache.org:
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@oliverlietz.de
wrote:
Whatever the approach is, if we want to allow multiple scripting
engines
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
Hi,
On Saturday, January 24, 2015, Oliver Lietz apa...@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
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
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@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
Hi
Am 23.01.2015 um 13:29 schrieb Radu Cotescu r...@apache.org:
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@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
Hi
Am 23.01.2015 um 11:55 schrieb Oliver Lietz apa...@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
On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz bdelacre...@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
On Fri, Jan 23, 2015 at 1:59 PM, Oliver Lietz apa...@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
On Fri, Jan 23, 2015 at 2:08 PM, Robert Munteanu rob...@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
On Friday 23 January 2015 13:33:37 Radu Cotescu wrote:
On Fri, Jan 23, 2015 at 1:15 PM, Bertrand Delacretaz bdelacre...@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?
!--
On Fri, Jan 23, 2015 at 11:30 AM, Felix Meschberger fmesc...@adobe.com wrote:
We could extend our ScriptResolution as well like this. If the file begins
with a line of the form
#!engine-nameCRLF
Why not. It's a bit costly as you need to read part of the script
during resolution but I
On Fri, Jan 23, 2015 at 11:55 AM, Oliver Lietz apa...@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
On Friday 23 January 2015 11:52:20 Bertrand Delacretaz wrote:
On Fri, Jan 23, 2015 at 11:30 AM, Felix Meschberger fmesc...@adobe.com
wrote:
We could extend our ScriptResolution as well like this. If the file begins
with a line of the form
#!engine-nameCRLF
Why not. It's a bit costly
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
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
On Fri, Jan 23, 2015 at 12:15 PM, Bertrand Delacretaz
bdelacre...@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
What about adding an additional property to the script resource?
Carsten
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
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 cziege...@apache.org:
What about adding an additional property to the
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.
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
On Fri, Jan 23, 2015 at 7:45 PM, Carsten Ziegeler cziege...@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
On Fri, Jan 23, 2015 at 4:21 PM, Chetan Mehrotra chetan.mehro...@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?
On Fri, Jan 23, 2015 at 3:41 PM, Chetan Mehrotra
chetan.mehro...@gmail.com wrote:
On Fri, Jan 23, 2015 at 7:59 PM, Radu Cotescu r...@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
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
On Fri, Jan 23, 2015 at 4:41 PM, Chetan Mehrotra chetan.mehro...@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...? :)
34 matches
Mail list logo
