Re: various questions regarding alternative scripting engines
Hi, On Feb 18, 2008 11:15 PM, Christian Sprecher <[EMAIL PROTECTED]> wrote: > ...I made a little PoC with the Groovy > ScriptingEngine and got it working in the launchpad-webapp, without > having to write one line of code... Cool! >... I could send it to someone, but I > think this stuff should be reviewed, especially the whole bundle > mechanism. Got any idea whom I could bother with this stuff? The best is to attach your patch to our JIRA issue tracker at https://issues.apache.org/jira/browse/SLING, with info about how to test it (or better: automated tests). -Bertrand
Re: various questions regarding alternative scripting engines
I would suggest keeping our focus on the javascript and JSP engines for now, until we have a first release of Sling. Other script engines might work, and they demonstrate that it's possible to integrate other languages, but personally I don't want to spend time improving them at the moment, we have more important things to do if we want to release soon. If others want to work on a specific scripting engine, or course, feel free to do it! -Bertrand (looking forward to the Scala scripting engine ;-) Sorry, only Groovy support here :). I made a little PoC with the Groovy ScriptingEngine and got it working in the launchpad-webapp, without having to write one line of code. I could send it to someone, but I think this stuff should be reviewed, especially the whole bundle mechanism. Got any idea whom I could bother with this stuff? Cheers Christian
Re: various questions regarding alternative scripting engines
On Feb 14, 2008 4:11 PM, Michael Marth <[EMAIL PROTECTED]> wrote: > ...I am just looking at the various scripting engines and ran into some probs. > Maybe someone can help?... I would suggest keeping our focus on the javascript and JSP engines for now, until we have a first release of Sling. Other script engines might work, and they demonstrate that it's possible to integrate other languages, but personally I don't want to spend time improving them at the moment, we have more important things to do if we want to release soon. If others want to work on a specific scripting engine, or course, feel free to do it! -Bertrand (looking forward to the Scala scripting engine ;-)
Re: various questions regarding alternative scripting engines
Hi all, Am Freitag, den 15.02.2008, 17:42 +0100 schrieb Michael Marth: > Hi Felix, > > when I use > var node = resource.adaptTo(Packages.javax.jcr.Node) > I get an exception > "Cannot find function adaptTo". > (I guess this is a temporary problem. Or does it work for you?) > > > > > Which is probably an error as it introduces an API in JavaScript which > > is not paralelled by the other APIs, we should probably remove that > > > > Rather than removing the very useful resource.node from esps for consistency > reasons I would kindly ask to introduce resource.node into other scripting > engines as well (would be consistent again :) ). We probably just cannot do that ;-) In fact, we should adhere to the original API for wrapper classes as much as possible (yes making use of the syntactic possibilities of the respective language) and not introduce new functionality. This is error-prone and not manageable. So the correct thing would really be to remove this from the JavaScript Resource wrapper. > > I believe that this can be done by injecting a node object within the > scripting engine implementation so that the Resource interface does not have > to be changed again. > > I think that this would be really helpful for Sling adoption because it > would make things easier for newbies. I agree with the others that adding a well-known "currentNode" object into the set of global variables for scripts. Regards Felix
Re: various questions regarding alternative scripting engines
On Feb 15, 2008 5:17 PM, David Nuescheler <[EMAIL PROTECTED]> wrote: > hi guys, > > > var node = resource.adaptTo(Packages.javax.jcr.Node) > > i personally think this sucks since it is going to be a > cryptic part in the beginning of all my esp scripts... You don't need this in ESP scripts, as those have wrappers which effectively hide this adaptTo call: resource.node works and gives you a ScriptableNode with convenience methods. The above adaptTo call (or something similar) is currently required for all scripting environments for which we did not create wrapper classes: Velocity, FreeMarker, Ruby, etc. -Bertrand
Re: various questions regarding alternative scripting engines
hi carsten, > Ok, we can still argue about the name though... :) I would call it just > "node" as we already have "resource" i agree that node would be intuitive. there are really two issues why i personally would mildly favor "currentNode". a) when working with jcr "node" is a very frequently used local variable (at least in my code ;) ) and we could avoid some collisions. b) in ujax on the client side we already called it "currentNode" and it is also called currentNode granted that both of these reason make for a rather weak bias, i am happy to be convinced otherwise. regards, david
Re: various questions regarding alternative scripting engines
David Nuescheler wrote: as a matter of fact i would like to see a "currentNode" variable in all the scripting environments, so i don't have to deal with the resource to begin with... +1 Ok, we can still argue about the name though... :) I would call it just "node" as we already have "resource" Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: various questions regarding alternative scripting engines
Hi Felix, when I use var node = resource.adaptTo(Packages.javax.jcr.Node) I get an exception "Cannot find function adaptTo". (I guess this is a temporary problem. Or does it work for you?) > Which is probably an error as it introduces an API in JavaScript which > is not paralelled by the other APIs, we should probably remove that Rather than removing the very useful resource.node from esps for consistency reasons I would kindly ask to introduce resource.node into other scripting engines as well (would be consistent again :) ). I believe that this can be done by injecting a node object within the scripting engine implementation so that the Resource interface does not have to be changed again. I think that this would be really helpful for Sling adoption because it would make things easier for newbies. Cheers Michael -- Michael Marth, http://dev.day.com
Re: various questions regarding alternative scripting engines
hi guys, > var node = resource.adaptTo(Packages.javax.jcr.Node) i personally think this sucks since it is going to be a cryptic part in the beginning of all my esp scripts... in my view this really should be hidden. the point of using scripting is to hide all the unnecessary detail of whats going on underneith... as a matter of fact i would like to see a "currentNode" variable in all the scripting environments, so i don't have to deal with the resource to begin with... regards, david On 2/15/08, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Hi, > > Am Freitag, den 15.02.2008, 11:43 +0100 schrieb Michael Marth: > > > Hi Felix, > > > > > > > > > But if I try to access something like $resource.node (which I would > have > > > > expected) Velocity does not recognize the expression. How do I get to > > > the > > > > node? Do I have the wrong syntax? I looked at the src of > JcrNodeResource > > > and > > > > expected to be able to use something like .node, .getNode() or similar. > > > > > > > > > I do not exactly know, how velocity maps Java objects. But a resource is > > > definitely a Resource and by conincidence a JcrNodeResource. In > > > addition, the JcrNodeResource.getNode() method is not public and not > > > part of the API. > > > > > > When you want to access the node of a resource you will have to adapt > > > the Resource to the Node class, something like: > > > > > > $resource.adaptTo(Node.class); > > > > > > But I am not exactly sure about the exact syntax. > > > > > > I am not exactly a velocity expert, but I tried this and had no success so > > far. But I also think that having to "cast" (sort of) a resource into a > node > > in a script is a bit weird. > > > This is not a cast its an adaption to another "view" of the same > resource. > > > > Especially, if you consider that > > resource.nodeworks in esp's. Could we not just get the node as an > > object right away? > > > Which is probably an error as it introduces an API in JavaScript which > is not paralelled by the other APIs, we should probably remove that > > > > > > I am aware that this has been discussed before, but I do not see any > > advantages of abstraction lost if the node object is available to the > > scripts if the resource in question is actually a node. > > > I do not quite understand this sentence. Do you want to say, the node is > lost due to the abstraction ? This is not the case as you can adapt the > resource to the node. > > > > The script needs to > > "know" it handles nodes anyway. > > > Yes, your particular script might now, but a script in general might not > care ... So we have the resource and that's it. You get the node by > adapting the resource. The question is how to use this API in your > favourite scripting language. > > E.g. in JavaScript you can do > >var node = resource.adaptTo(Packages.javax.jcr.Node) > > maybe in Velocity the equivalent might be > >#set( $node = $resource.adaptTo(javax.jcr.Node) ) > > Regards > Felix > > > > > WDYT? > > Michael > >
Re: various questions regarding alternative scripting engines
Hi, Am Freitag, den 15.02.2008, 11:43 +0100 schrieb Michael Marth: > Hi Felix, > > > > > > But if I try to access something like $resource.node (which I would have > > > expected) Velocity does not recognize the expression. How do I get to > > the > > > node? Do I have the wrong syntax? I looked at the src of JcrNodeResource > > and > > > expected to be able to use something like .node, .getNode() or similar. > > > > > > I do not exactly know, how velocity maps Java objects. But a resource is > > definitely a Resource and by conincidence a JcrNodeResource. In > > addition, the JcrNodeResource.getNode() method is not public and not > > part of the API. > > > > When you want to access the node of a resource you will have to adapt > > the Resource to the Node class, something like: > > > > $resource.adaptTo(Node.class); > > > > But I am not exactly sure about the exact syntax. > > > I am not exactly a velocity expert, but I tried this and had no success so > far. But I also think that having to "cast" (sort of) a resource into a node > in a script is a bit weird. This is not a cast its an adaption to another "view" of the same resource. > Especially, if you consider that > resource.nodeworks in esp's. Could we not just get the node as an > object right away? Which is probably an error as it introduces an API in JavaScript which is not paralelled by the other APIs, we should probably remove that > > I am aware that this has been discussed before, but I do not see any > advantages of abstraction lost if the node object is available to the > scripts if the resource in question is actually a node. I do not quite understand this sentence. Do you want to say, the node is lost due to the abstraction ? This is not the case as you can adapt the resource to the node. > The script needs to > "know" it handles nodes anyway. Yes, your particular script might now, but a script in general might not care ... So we have the resource and that's it. You get the node by adapting the resource. The question is how to use this API in your favourite scripting language. E.g. in JavaScript you can do var node = resource.adaptTo(Packages.javax.jcr.Node) maybe in Velocity the equivalent might be #set( $node = $resource.adaptTo(javax.jcr.Node) ) Regards Felix > > WDYT? > Michael
Re: various questions regarding alternative scripting engines
Hi Felix, > > > But if I try to access something like $resource.node (which I would have > > expected) Velocity does not recognize the expression. How do I get to > the > > node? Do I have the wrong syntax? I looked at the src of JcrNodeResource > and > > expected to be able to use something like .node, .getNode() or similar. > > > I do not exactly know, how velocity maps Java objects. But a resource is > definitely a Resource and by conincidence a JcrNodeResource. In > addition, the JcrNodeResource.getNode() method is not public and not > part of the API. > > When you want to access the node of a resource you will have to adapt > the Resource to the Node class, something like: > > $resource.adaptTo(Node.class); > > But I am not exactly sure about the exact syntax. I am not exactly a velocity expert, but I tried this and had no success so far. But I also think that having to "cast" (sort of) a resource into a node in a script is a bit weird. Especially, if you consider that resource.nodeworks in esp's. Could we not just get the node as an object right away? I am aware that this has been discussed before, but I do not see any advantages of abstraction lost if the node object is available to the scripts if the resource in question is actually a node. The script needs to "know" it handles nodes anyway. WDYT? Michael
Re: various questions regarding alternative scripting engines
Am Donnerstag, den 14.02.2008, 16:11 +0100 schrieb Michael Marth: > Hi, > > I am just looking at the various scripting engines and ran into some probs. > Maybe someone can help? > > Velocity > --- > I have installed the velocity bundle and want to do the first test in > Bertrand's 15min tutorial with a velocity script. Saving this as > html.vltworks OK: > > > $resource.getResourceType() > $resource.getPath() > > > I get something like: > foo/bar > /content/mynode > > But if I try to access something like $resource.node (which I would have > expected) Velocity does not recognize the expression. How do I get to the > node? Do I have the wrong syntax? I looked at the src of JcrNodeResource and > expected to be able to use something like .node, .getNode() or similar. I do not exactly know, how velocity maps Java objects. But a resource is definitely a Resource and by conincidence a JcrNodeResource. In addition, the JcrNodeResource.getNode() method is not public and not part of the API. When you want to access the node of a resource you will have to adapt the Resource to the Node class, something like: $resource.adaptTo(Node.class); But I am not exactly sure about the exact syntax. > > Freemarker > > Almost the same as velocity. If I save this as html.ftl > > ${resource.resourceType} > ${resource.path} > > > This works, but this > > > ${resource.node} > Same here: node is neither a property nor is there a public getter. Use the adaptTo method. > > Gives an exception: Expression resource.node is undefined on line 3, column > 3 in /apps/foo/bar/html.ftl. The problematic instruction: -- ==> ${ > resource.node} [on line 3, column 1 in /apps/foo/bar/html.ftl] -- > Java backtrace for programmers: -- > freemarker.core.InvalidReferenceException: Expression resource.node is > undefined on line 3, column 3 in /apps/foo/bar/html.ftl > > Ruby > --- > Saving anything as html.erb gives me an exception when I do a request like > above. I installed the scripting bundle just like for velocity and > freemarker. The console says things are fine. The exception is: > > org/jruby/runtime/callback/InvocationCallback (500) > The requested URL /content/mynode.html resulted in an error in Sling Default > Error Handler Servlet. > Exception: > java.lang.NoClassDefFoundError: > org/jruby/runtime/callback/InvocationCallback > > Is there additional installation work to be done for Ruby? Not sure, what the problem might be here... Could it be that the bundling is incomplete ? Paddy do you have an idea ? Regards Felix