You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Felix Meschberger <fm...@gmail.com> on 2009/04/06 09:01:08 UTC
Re: Support XML-compliant script delimiter
Hi Vidar,
Vidar Ramdal schrieb:
> This is off the top of my head from the Jackrabbit/Sling BOF at ApacheCon:
>
> It would be of great use to support another script delimiter in script
> files. The current delimiters (<% and %>) does not play well with most
> IDEs (at least the one I've tried). At least in IntelliJ IDEA, you can
> mix XML/HTML with other languages (and have auto-completion and error
> checking) only if it is delimited by a valid XML element.
>
> We have at least two options here:
>
> 1. Use the standard HTML <script> element, and add a non-standard
> attribute to specify that the script is to be executed server-side. In
> ASP (if I remember correctly) you would use <script runat="server"
> type="text/javascript"> to specify a block of server-side JavaScript.
>
> 2. Use a namespaced element, like <sling:javascript>.
>
> The latter is perhaps the cleanest option, but it might cause trouble
> for those who still insist on writing HTML (and not XHTML).
>
> Any opinions?
For the background: The current syntax we use for ESP scriptlets and
expressions is borrowed from the JSP specification for traditional JSP
pages.
Nowadays, the JSP specification als defines a pure XML syntax for JSP
scripts, which requires to replace the old style syntax elements with
proper tags:
<%= expression %>
--> <jsp:expression>expression</jsp:expression>
<% scriptlet %>
--> <jsp:scriptlet>scriptlet</jsp:scriptlet>
Currently the ESP syntax is handled by a very simple, character stream
based reader, the EspReader, which just wraps the script reader and
converts ESP syntax to plain ECMA syntax on-the-fly (no intermediate
file generation and preserving line numbers).
I could imagine the following: (1) Extend EspReader to support an
extended syntax or (2) create a new parser which does not support the
simple syntax but the new tag-based syntax.
I would opt for #2 and call this for the extensions .espx (like .jspx
for JSP Documents).
WDYT ?
Any volounteers ;-)
Regards
Felix
>
Re: Support XML-compliant script delimiter
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Apr 6, 2009 at 11:00 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Yes, maybe this should be parsed and then "serialized" again to plain
> ECMAScript code for the Rhino Interpreter ... This raises now a
> performance concern (with me at least).
For now I've created SLING-912 for this. I'll see if I can get time to
look at it, or, if anyone else feels inspired, be my guest.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070
Re: Support for Java Scripting Script Precompilation
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Mon, Apr 6, 2009 at 11:32 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> Hi,
>>
>> Bertrand Delacretaz schrieb:
>>> On Mon, Apr 6, 2009 at 11:00 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>>> ...We should then probably also extend the Rhino script engine to cache
>>>> compiled ecma scripts and reuse them, similar to what the JSP script
>>>> engine does (no we probably don't need to write class files)....
>>> ...Rhino does provide a compiler
>>> (https://developer.mozilla.org/en/Rhino_JavaScript_Compiler)...
>
>> ...How about this approach, thus also leveraging the full scope of JSR 223
>> (Java Scripting): The Java Scripting API provides API to allow for
>> precompiled scripting languages. By leveraging this mechanism we can add
>> support for precompiled scripts and enhanced performance to all
>> scripting languages.
>>
>> We maintain a script cache in the Scripting Core bundle. This cache has
>> the following attributes:
>>
>> * Indexed by script path name, entries are weak or soft references
>> to JSR-223 CompiledScript instances (and some time stamp to help
>> decide for recompilation)
>
> Ok. I think this cache should also have some form of size limitation -
> maybe simply limit the total number of CompiledScript instances in the
> cache, and purge least recently used entries when that limit is
> reached?
Sure. And of course the limit would be configurable ;-)
I just failed to add this other restriction
Regards
Felix
>
>> ... * When trying to run a script the following steps take place:
>>
>> - check for a cache entry
>> - if existing and script source is not more recent
>> than the cache entry, us it and we are done
>> - if the cache entry is outdated, remove it and continue
>
> ok
>
>> - check whether the ScriptEngine allows precompilation.
>> - if yes: compile the script, enter it into the cache
>> and run the CompiledScript
>> - if no: just have the ScriptEngine read and run the
>> script.
>
> ok
>
>> This can already be easily used for our own JSP Script Engine. It may
>> probably also be used for the Groovy ScriptEngine, since it supports
>> script precompilation. For our own Rhino ScriptEngine we would just add
>> support for this and be done.
>
> Sound great!
> -Bertrand
>
Re: Support for Java Scripting Script Precompilation (was: Support
XML-compliant script delimiter)
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Apr 6, 2009 at 11:32 AM, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Bertrand Delacretaz schrieb:
>> On Mon, Apr 6, 2009 at 11:00 AM, Felix Meschberger <fm...@gmail.com> wrote:
>>> ...We should then probably also extend the Rhino script engine to cache
>>> compiled ecma scripts and reuse them, similar to what the JSP script
>>> engine does (no we probably don't need to write class files)....
>>
>> ...Rhino does provide a compiler
>> (https://developer.mozilla.org/en/Rhino_JavaScript_Compiler)...
> ...How about this approach, thus also leveraging the full scope of JSR 223
> (Java Scripting): The Java Scripting API provides API to allow for
> precompiled scripting languages. By leveraging this mechanism we can add
> support for precompiled scripts and enhanced performance to all
> scripting languages.
>
> We maintain a script cache in the Scripting Core bundle. This cache has
> the following attributes:
>
> * Indexed by script path name, entries are weak or soft references
> to JSR-223 CompiledScript instances (and some time stamp to help
> decide for recompilation)
Ok. I think this cache should also have some form of size limitation -
maybe simply limit the total number of CompiledScript instances in the
cache, and purge least recently used entries when that limit is
reached?
> ... * When trying to run a script the following steps take place:
>
> - check for a cache entry
> - if existing and script source is not more recent
> than the cache entry, us it and we are done
> - if the cache entry is outdated, remove it and continue
ok
>
> - check whether the ScriptEngine allows precompilation.
> - if yes: compile the script, enter it into the cache
> and run the CompiledScript
> - if no: just have the ScriptEngine read and run the
> script.
ok
> This can already be easily used for our own JSP Script Engine. It may
> probably also be used for the Groovy ScriptEngine, since it supports
> script precompilation. For our own Rhino ScriptEngine we would just add
> support for this and be done.
Sound great!
-Bertrand
Support for Java Scripting Script Precompilation (was: Support XML-compliant
script delimiter)
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Mon, Apr 6, 2009 at 11:00 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...We should then probably also extend the Rhino script engine to cache
>> compiled ecma scripts and reuse them, similar to what the JSP script
>> engine does (no we probably don't need to write class files)....
>
> This is something that we should do in any case, to improve ESP
> scripting performance.
>
> Rhino does provide a compiler
> (https://developer.mozilla.org/en/Rhino_JavaScript_Compiler), haven't
> tested it yet.
This works, and I used it before ...
Rhino always runs scripts in two phases: "compilation" and "execution".
The result of the first step is generally an instance of the Script
interface. This interface has a method to execute the script, which is
call by RHino in the second phase.
How about this approach, thus also leveraging the full scope of JSR 223
(Java Scripting): The Java Scripting API provides API to allow for
precompiled scripting languages. By leveraging this mechanism we can add
support for precompiled scripts and enhanced performance to all
scripting languages.
We maintain a script cache in the Scripting Core bundle. This cache has
the following attributes:
* Indexed by script path name, entries are weak or soft references
to JSR-223 CompiledScript instances (and some time stamp to help
decide for recompilation)
* When trying to run a script the following steps take place:
- check for a cache entry
- if existing and script source is not more recent
than the cache entry, us it and we are done
- if the cache entry is outdated, remove it and continue
- check whether the ScriptEngine allows precompilation.
- if yes: compile the script, enter it into the cache
and run the CompiledScript
- if no: just have the ScriptEngine read and run the
script.
This can already be easily used for our own JSP Script Engine. It may
probably also be used for the Groovy ScriptEngine, since it supports
script precompilation. For our own Rhino ScriptEngine we would just add
support for this and be done.
WDYT ?
Regards
Felix
Re: Support XML-compliant script delimiter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Apr 6, 2009 at 11:00 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...We should then probably also extend the Rhino script engine to cache
> compiled ecma scripts and reuse them, similar to what the JSP script
> engine does (no we probably don't need to write class files)....
This is something that we should do in any case, to improve ESP
scripting performance.
Rhino does provide a compiler
(https://developer.mozilla.org/en/Rhino_JavaScript_Compiler), haven't
tested it yet.
-Bertrand
Re: Support XML-compliant script delimiter
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Yes, maybe this should be parsed and then "serialized" again to plain
ECMAScript code for the Rhino Interpreter ... This raises now a
performance concern (with me at least).
We should then probably also extend the Rhino script engine to cache
compiled ecma scripts and reuse them, similar to what the JSP script
engine does (no we probably don't need to write class files).
Regards
Felix
Vidar Ramdal schrieb:
>> Vidar Ramdal schrieb:
>>> This is off the top of my head from the Jackrabbit/Sling BOF at ApacheCon:
>>>
>>> It would be of great use to support another script delimiter in script
>>> files. The current delimiters (<% and %>) does not play well with most
>>> IDEs (at least the one I've tried). At least in IntelliJ IDEA, you can
>>> mix XML/HTML with other languages (and have auto-completion and error
>>> checking) only if it is delimited by a valid XML element.
>>>
>>> We have at least two options here:
>>>
>>> 1. Use the standard HTML <script> element, and add a non-standard
>>> attribute to specify that the script is to be executed server-side. In
>>> ASP (if I remember correctly) you would use <script runat="server"
>>> type="text/javascript"> to specify a block of server-side JavaScript.
>>>
>>> 2. Use a namespaced element, like <sling:javascript>.
>>>
>>> The latter is perhaps the cleanest option, but it might cause trouble
>>> for those who still insist on writing HTML (and not XHTML).
>>>
>>> Any opinions?
>
> On Mon, Apr 6, 2009 at 9:01 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> For the background: The current syntax we use for ESP scriptlets and
>> expressions is borrowed from the JSP specification for traditional JSP
>> pages.
>>
>> Nowadays, the JSP specification als defines a pure XML syntax for JSP
>> scripts, which requires to replace the old style syntax elements with
>> proper tags:
>>
>> <%= expression %>
>> --> <jsp:expression>expression</jsp:expression>
>>
>> <% scriptlet %>
>> --> <jsp:scriptlet>scriptlet</jsp:scriptlet>
>>
>> Currently the ESP syntax is handled by a very simple, character stream
>> based reader, the EspReader, which just wraps the script reader and
>> converts ESP syntax to plain ECMA syntax on-the-fly (no intermediate
>> file generation and preserving line numbers).
>>
>> I could imagine the following: (1) Extend EspReader to support an
>> extended syntax or (2) create a new parser which does not support the
>> simple syntax but the new tag-based syntax.
>>
>> I would opt for #2 and call this for the extensions .espx (like .jspx
>> for JSP Documents).
>>
>> WDYT ?
>
> Yep, after looking at EspReader, it does not look easy to extend it.
> .espx sounds good to me.
>
> But should the .espx in fact be an XML parser (thus, fail if the input
> document is not valid XML)?
>
Re: Support XML-compliant script delimiter
Posted by Felix Meschberger <fm...@gmail.com>.
HI,
Bertrand Delacretaz schrieb:
> On Mon, Apr 6, 2009 at 11:23 AM, Felix Meschberger <fm...@gmail.com> wrote:
>> ...If down-stream users want to not pay the price for well-formedness, they
>> should use the traditional approach using <%= %>. Event there,
>> developers are required to apply some form of well-formedness....
>
> Ok, as long as we don't deprecate the loose <%= %> syntax I see your point.
Why should we ? I think we could happily support both syntaxes and have
the ECMAEscript script engine use the extension to decide:
.ecma -> plain ECMAScript, no markup
.esp -> old markup (<%= %>, <% %>)
.espx -> XML markup (well-formedness required)
>> ...So, I would be all for using an XML parser for espx scripts. This
>> requires more from the programmer but gives back much more....
>
> Not convinced, but if there's choice, people can pick their poison ;-)
Regards
Felix
Re: Support XML-compliant script delimiter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Apr 6, 2009 at 11:23 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ...If down-stream users want to not pay the price for well-formedness, they
> should use the traditional approach using <%= %>. Event there,
> developers are required to apply some form of well-formedness....
Ok, as long as we don't deprecate the loose <%= %> syntax I see your point.
> ...So, I would be all for using an XML parser for espx scripts. This
> requires more from the programmer but gives back much more....
Not convinced, but if there's choice, people can pick their poison ;-)
-Bertrand
Re: Support XML-compliant script delimiter
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Bertrand Delacretaz schrieb:
> On Mon, Apr 6, 2009 at 11:14 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> On Mon, Apr 6, 2009 at 11:06 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>> I'd much prefer a permissive parser that only uses XMLish tags to
>>> delimit code sections - assuming that meets your requirement of editor
>>> friendliness.
>> I think so, yes. Although a pure XML parser would be much easier to
>> implement, I guess :)
>
> Yes, but what a pain for users downstream, if all scripts have to be
> well-formed XML!
Well, JSP documents must also be well-formed. So I think, it would be
natural to require this here, too.
If down-stream users want to not pay the price for well-formedness, they
should use the traditional approach using <%= %>. Event there,
developers are required to apply some form of well-formedness.
So, I would be all for using an XML parser for espx scripts. This
requires more from the programmer but gives back much more.
Regards
Felix
Re: Support XML-compliant script delimiter
Posted by Vidar Ramdal <vi...@idium.no>.
On Mon, Apr 6, 2009 at 11:17 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> On Mon, Apr 6, 2009 at 11:14 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> On Mon, Apr 6, 2009 at 11:06 AM, Bertrand Delacretaz
>> <bd...@apache.org> wrote:
>>> I'd much prefer a permissive parser that only uses XMLish tags to
>>> delimit code sections - assuming that meets your requirement of editor
>>> friendliness.
>>
>> I think so, yes. Although a pure XML parser would be much easier to
>> implement, I guess :)
>
> Yes, but what a pain for users downstream, if all scripts have to be
> well-formed XML!
Well, depends on the tools you use. If you use an XML editor, I'd say
it's easier to avoid syntax errors - and even get valid XHTML in the
end.
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070
Re: Support XML-compliant script delimiter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Apr 6, 2009 at 11:14 AM, Vidar Ramdal <vi...@idium.no> wrote:
> On Mon, Apr 6, 2009 at 11:06 AM, Bertrand Delacretaz
> <bd...@apache.org> wrote:
>> I'd much prefer a permissive parser that only uses XMLish tags to
>> delimit code sections - assuming that meets your requirement of editor
>> friendliness.
>
> I think so, yes. Although a pure XML parser would be much easier to
> implement, I guess :)
Yes, but what a pain for users downstream, if all scripts have to be
well-formed XML!
-Bertrand
Re: Support XML-compliant script delimiter
Posted by Vidar Ramdal <vi...@idium.no>.
> On Mon, Apr 6, 2009 at 10:45 AM, Vidar Ramdal <vi...@idium.no> wrote:
>> But should the .espx in fact be an XML parser (thus, fail if the input
>> document is not valid XML)?
On Mon, Apr 6, 2009 at 11:06 AM, Bertrand Delacretaz
<bd...@apache.org> wrote:
> I'd much prefer a permissive parser that only uses XMLish tags to
> delimit code sections - assuming that meets your requirement of editor
> friendliness.
I think so, yes. Although a pure XML parser would be much easier to
implement, I guess :)
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070
Re: Support XML-compliant script delimiter
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Apr 6, 2009 at 10:45 AM, Vidar Ramdal <vi...@idium.no> wrote:
> ...after looking at EspReader, it does not look easy to extend it.
> .espx sounds good to me....
I was going to say "do we really need a new extension", but thinking
about it having a different extension with a different parser sounds
easier to manage.
> But should the .espx in fact be an XML parser (thus, fail if the input
> document is not valid XML)?
I'd much prefer a permissive parser that only uses XMLish tags to
delimit code sections - assuming that meets your requirement of editor
friendliness.
-Bertrand
Re: Support XML-compliant script delimiter
Posted by Vidar Ramdal <vi...@idium.no>.
> Vidar Ramdal schrieb:
>> This is off the top of my head from the Jackrabbit/Sling BOF at ApacheCon:
>>
>> It would be of great use to support another script delimiter in script
>> files. The current delimiters (<% and %>) does not play well with most
>> IDEs (at least the one I've tried). At least in IntelliJ IDEA, you can
>> mix XML/HTML with other languages (and have auto-completion and error
>> checking) only if it is delimited by a valid XML element.
>>
>> We have at least two options here:
>>
>> 1. Use the standard HTML <script> element, and add a non-standard
>> attribute to specify that the script is to be executed server-side. In
>> ASP (if I remember correctly) you would use <script runat="server"
>> type="text/javascript"> to specify a block of server-side JavaScript.
>>
>> 2. Use a namespaced element, like <sling:javascript>.
>>
>> The latter is perhaps the cleanest option, but it might cause trouble
>> for those who still insist on writing HTML (and not XHTML).
>>
>> Any opinions?
On Mon, Apr 6, 2009 at 9:01 AM, Felix Meschberger <fm...@gmail.com> wrote:
> For the background: The current syntax we use for ESP scriptlets and
> expressions is borrowed from the JSP specification for traditional JSP
> pages.
>
> Nowadays, the JSP specification als defines a pure XML syntax for JSP
> scripts, which requires to replace the old style syntax elements with
> proper tags:
>
> <%= expression %>
> --> <jsp:expression>expression</jsp:expression>
>
> <% scriptlet %>
> --> <jsp:scriptlet>scriptlet</jsp:scriptlet>
>
> Currently the ESP syntax is handled by a very simple, character stream
> based reader, the EspReader, which just wraps the script reader and
> converts ESP syntax to plain ECMA syntax on-the-fly (no intermediate
> file generation and preserving line numbers).
>
> I could imagine the following: (1) Extend EspReader to support an
> extended syntax or (2) create a new parser which does not support the
> simple syntax but the new tag-based syntax.
>
> I would opt for #2 and call this for the extensions .espx (like .jspx
> for JSP Documents).
>
> WDYT ?
Yep, after looking at EspReader, it does not look easy to extend it.
.espx sounds good to me.
But should the .espx in fact be an XML parser (thus, fail if the input
document is not valid XML)?
--
Vidar S. Ramdal <vi...@idium.no> - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070