[xwiki-devs] [PROPOSAL] JSR223 (Scripting for the Java Platform) and XWiki context
Hi devs, In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context). The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that. I can see several general rules: 1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext) 2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs. 3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity. There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding If think the best is 4) for now. WDYT ? -- Thomas Mortagne
Thomas Mortagne wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
+1 for 4) I'm not sure 2) is possible, since a scripting language might need to actually have a certain class in there (although this is bad, it is possible, we don't control the code that others write). So, -0 for 2) -1 for 3) -- Sergiu Dumitriu http://purl.org/net/sergiu/
On Wed, Jun 10, 2009 at 3:28 PM, Thomas Mortagne <[email protected]>wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
+1 for 4 Thanks. - Asiri
On Jun 10, 2009, at 11:58 AM, Thomas Mortagne wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
WDYT ?
Can we talk to someone close to this JSR to understand why there's this "context" binding? I'd really like to understand the rationale before deciding. I still don't understand why it's used and why it's not using the reserved javax.script prefix. Thanks -Vincent
On Wed, Jun 10, 2009 at 12:22, Vincent Massol<[email protected]> wrote:
On Jun 10, 2009, at 11:58 AM, Thomas Mortagne wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
WDYT ?
Can we talk to someone close to this JSR to understand why there's this "context" binding?
I'd really like to understand the rationale before deciding. I still don't understand why it's used and why it's not using the reserved javax.script prefix.
I don't really understand it either but the spec are pretty clear about that and all the JSR223 engines implementations I looked at force the "context" binding to be the ScriptContext so we will have to find a solution.
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
On Wed, Jun 10, 2009 at 11:58, Thomas Mortagne<[email protected]> wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
See http://jcp.org/aboutJava/communityprocess/final/jsr223/index.html for JSR223 specifications.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
WDYT ?
-- Thomas Mortagne
-- Thomas Mortagne
Thomas Mortagne wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
+1 for 4) too.
WDYT ?
Four +1 for 4) and no other votes. Doing it now. On Wed, Jun 10, 2009 at 11:58, Thomas Mortagne<[email protected]> wrote:
Hi devs,
In velocity scripting and groovy we have the binding "context" containing com.xpn.xwiki.api.Context (which should change at some point when we will have the new model, anyway the point is that it contains a XWiki custom context).
The problem is that "context" binding is reserved in JSR 223 (which sounds very restrictive to me since there is no reason for that binding to be technically reserved) so we can't have our own context binding in all JSR223 based macros which mean all the macro executing script (Velocity macro is still using old api but at some point it will use standard ScriptContext). I managed to do a ugly hack for groovy macro to have context being com.xpn.xwiki.api.Context but we need to find a generic rule about that.
I can see several general rules:
1) change "context" binding for something like "xcontext": that's the cleaner easier way from JSR223 POV but it means breaking all existing script using "context" binding in 2.0 syntax. This is not an issue jruby, jython etc... which are not yet used but it makes the ocnversion between 1.0 syntax and 2.0 syntax harder for Velocity and Groovy scripting (note that it's not difficult for the 1.0->2.0 converter to change $context to $xcontext)
2) make com.xpn.api.Context implements ScriptContext interface: this means we need to make the ScriptContext a XWiki context behind the scene for it to be used in both needs.
3) we reimplement our own JSR223 ScriptEngine and don't use the standard to be able to put anything we want in the "context" binding: this could mean lot's of work and no one could just put groovy (or any other engine embedding JSR223 bridge) jar in lib/ folder and have groovy scripting in XWiki anymore which is the goal of the generic {{script}} macro
I'm -1 for 3), it would make using JSR223 useless. Now between 1) and 2) i'm not sure, I'm 1) for future languages support and even for Groovy but it's a very big move for Velocity.
There is also the 4) we do 1) by default and we introduce the "xcontext" binding in Velocity and deprecate the "context" binding
If think the best is 4) for now.
WDYT ?
-- Thomas Mortagne
-- Thomas Mortagne
participants (5)
-
Asiri Rathnayake -
Marius Dumitru Florea -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol