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 <fmesc...@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)? >
