Re: How to I chmod -x on Javascript files

[Lars Trieloff]

You can get the contents of the script by accessing it directly, without any additional extensions or selectors, so

something.es = the ES script





regards,

Lars


On 20.02.2008, at 19:49, Peter Svensson wrote:

something.es.xyz = the ES scripts output (provided there is a script engine registered for *.es) But what I need is the list of properties and child nodes of something.es (which is a nt:file anyway if you create it with WebDAV), so that does not work.

Do I understand correctly that it would be possible to get the contents of an .es script without executing it, by setting the resource type to nt:file?

Then I'd +1, absolutely.

Cheers,
PS


wrote:

On Wed, Feb 20, 2008 at 7:42 PM, Tobias Bocanegra <[EMAIL PROTECTED] >

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


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.


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.

my suggestion is to remove the ".js" mapping to rhino scripts and
replace it with the ".es" extension.

WDYT ?
regards, toby

On 2/20/08, Lars Trieloff <[EMAIL PROTECTED]> wrote:

if you need to execute it on the server, you need to add some extension. however, i think that it would be good to differentiate between client

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


Cheers,
PS

On Wed, Feb 20, 2008 at 5:32 PM, Lars Trieloff <[EMAIL PROTECTED]>
wrote:

work hierarchically) which just copies those files to .esp extensions.

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

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:

Bunkai, where you actually want to edit the scripts you are going to

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.

has
an extension. Therefore the request /dojo/dojo/AdapterRegistry.js
(no
extension) is not executed by the given request is executed
(extension
json).


is


We might fix this by using .ecma instead of .js for server-side
JavaScript files.

WDYT ?

Yes, we execute a resource, which adapts to Servlet, if the request This collision between streaming the script and executing the script an issue only with .js files AFAIK. The reason for this is, that the JavaScript ScriptEngineFactory is registered for .js and .esp files.

but
the current code deviates from this convention.

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,

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

--

T +41 61 226 98 98, F +41 61 226 98 97

-----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel -----------------------------------------------< http://www.day.com >---

--
Lars Trieloff
[EMAIL PROTECTED]
http://weblogs.goshaky.com/weblogs/lars

smime.p7s
Description: S/MIME cryptographic signature