Hi, Am Mittwoch, den 20.02.2008, 10:42 -0800 schrieb Tobias Bocanegra: > if a script is stored as nt:file, it can be retrieved as such, using > the direct url. eg: > > http://localhost:8888/dojo/dojo/AdapterRegistry.js > > if you need to execute it on the server, you need to add some extension. eg: > > http://localhost:8888/dojo/dojo/AdapterRegistry.js.html > > afaik the current extension mapping does not allow override of the > default behavior of scripts. so: > > http://localhost:8888/dojo/dojo/AdapterRegistry.js.1.json > > does not work.
Wrong, this does work, I don't know why it should not ? It would just call the AdapterRegistry.js script exactly the same when requesting AdapterRegistry.js.html. > > however, i think that it would be good to differentiate between client > and server sided scripts. > most common is ".js" though of a client sided script, so should never > be executed on the server. > ".esp" is somehow a jsp derivate that includes a parser for the <% %> > tags. if a pure ecma script is to be executed on the server, it would > call them ".es". the question is where the output will go? > probably to system.out or to some execution context writer. You might ask the same question for servlets ;-) Pure ECMA scripts have to get the output just like any servlet. Actually the output is provided as the global out variable to which scripts may write. > > my suggestion is to remove the ".js" mapping to rhino scripts and > replace it with the ".es" extension. > > WDYT ? This is what I already proposed, except that I proposed ecma instead of es. Regards Felix > regards, toby > > On 2/20/08, Lars Trieloff <[EMAIL PROTECTED]> wrote: > > Another hackish solution would be the introduction of a do-not-execute > > header or selector or request parameters. > > > > The main problem is the ambiguity that these PHP-style scripts > > introduce, which itselfs leads to a hackish programming style. > > > > On 20.02.2008, at 18:42, Peter Svensson wrote: > > > > > One hackish solution could be for Bunkai to save the scripts > > > as .esp.src or > > > somethin like that, and then I could have a "deplot" button (which > > > could > > > work hierarchically) which just copies those files to .esp extensions. > > > > > > Cheers, > > > PS > > > > > > On Wed, Feb 20, 2008 at 5:32 PM, Lars Trieloff <[EMAIL PROTECTED]> > > > wrote: > > > > > >> After thinking a bit about it, I think that neither renaming server- > > >> side scripts to ecma nor having a designated /apps or /libs path nor > > >> having an executable bit would solve my problem in the light of > > >> Bunkai, where you actually want to edit the scripts you are going to > > >> execute later. > > >> > > >> I do not really understand yet when scripts are supposed to be > > >> executed on request and where this behavior is desired (it feels a > > >> bit > > >> like PHP to me) > > >> > > >> regards, > > >> > > >> Lars > > >> > > >> On 20.02.2008, at 15:37, Felix Meschberger wrote: > > >> > > >>> Hi, > > >>> > > >>> Am Mittwoch, den 20.02.2008, 14:33 +0100 schrieb Lars Trieloff: > > >>>> I was unable to get the JSON representation (curl -u admin:admin > > >> http://localhost:8888/dojo/dojo/AdapterRegistry.js.1.json) > > >>>> because Sling tries to execute the JS script then and gives me > > >>>> following error message: > > >>>> > > >>>> org.mozilla.javascript.EcmaError: ReferenceError: "dojo" is not > > >>>> defined. (/dojo/dojo/AdapterRegistry.js#1) ... and so on. > > >>> > > >>> Yes, we execute a resource, which adapts to Servlet, if the request > > >>> has > > >>> an extension. Therefore the request /dojo/dojo/AdapterRegistry.js > > >>> (no > > >>> extension) is not executed by the given request is executed > > >>> (extension > > >>> json). > > >>> > > >>> This collision between streaming the script and executing the script > > >>> is > > >>> an issue only with .js files AFAIK. The reason for this is, that the > > >>> JavaScript ScriptEngineFactory is registered for .js and .esp files. > > >>> > > >>> We might fix this by using .ecma instead of .js for server-side > > >>> JavaScript files. > > >>> > > >>> WDYT ? > > >>> > > >>>> > > >>>> So my question is how do I define subtrees that are not executable, > > >>>> even if they contain a script. I think microsling originally had a > > >>>> convention that only scripts in /scripts were actually executable, > > >>>> but > > >>>> the current code deviates from this convention. > > >>> > > >>> This depends from where you are looking from: I would say, > > >>> microsling > > >>> devaiated from Sling in that respect ;-) > > >>> > > >>> Regards > > >>> Felix > > >>> > > >> > > >> -- > > >> Lars Trieloff > > >> [EMAIL PROTECTED] > > >> http://weblogs.goshaky.com/weblogs/lars > > >> > > >> > > > > -- > > Lars Trieloff > > [EMAIL PROTECTED] > > http://weblogs.goshaky.com/weblogs/lars > > > > > > > >
