<
From version < 38.1 >
edited by Vincent Massol
on 2012/05/18
To version < 39.1 >
edited by Sergiu Dumitriu
on 2012/05/19
>
Change comment: More thorough description of the advantages of each scripting language

Summary

Details

Page properties
Author
... ... @@ -1,1 +1,1 @@
1 -XWiki.VincentMassol
1 +XWiki.Sergiu
Content
... ... @@ -14,10 +14,12 @@
14 14  
15 15  = Choosing a Scripting language =
16 16  
17 -Since XWiki supports several scripting languages you might be wondering which one to use.
17 +Since XWiki supports several scripting languages you might be wondering which one to use. Most of the code written by XWiki developers is in Velocity, with a few more complex extensions written in Groovy; these two are thoroughly tried and tested, so they are both a safe bet. The other languages //should// work just as well, but there are less developers that could help answering any questions.
18 18  
19 +== Velocity ==
20 +
19 19  The first thing to know is that Velocity is different from the other scripting languages on 2 aspects:
20 -* It's a templating language rather than a pure scripting language, which means that its content is actually wiki markup interspersed with Velocity directives whereas pure scripting languages are written in that language and they need to output wiki markup. For example:(((
22 +* It's a templating language rather than a pure scripting language, which means that its content is actually wiki markup interspersed with Velocity directives, whereas pure scripting languages are written in that language and they need to explicitly output wiki markup. For example:(((
21 21  Velocity:
22 22  
23 23  {{code}}
... ... @@ -34,8 +34,24 @@
34 34  {{/groovy}}
35 35  {{/code}}
36 36  )))
37 -* It doesn't require special permissions since it runs in a Sandbox. Other scripting language require the user to have Programming Rights to execute them. Note that starting with XWiki 4.1 we've introduced a [[Sandbox for Groovy>>platform:AdminGuide.Configuration#HSecuringGroovyScripts]] too but it's still in an early stage.
39 +* It doesn't require special permissions since it runs in a Sandbox, with access to only a few safe objects, and each API call will check the rights configured in the wiki, forbidding access to resources or actions that the current user shouldn't be allowed to retrieve/perform. Other scripting language require the user that wrote the script to have Programming Rights to execute them, but except this initial precondition, access is granted to all the resources on the server. Note that starting with XWiki 4.1 we've introduced a [[Sandbox for Groovy>>platform:AdminGuide.Configuration#HSecuringGroovyScripts]] too, but it's still in an early stage.
38 38  
41 +Being a templating engine, Velocity doesn't offer many means of structuring code. In fact, there's only one useful directive in this regard, ###macro##. Without programming rights, it's impossible to instantiate new objects, except literals and those safely offered by the XWiki APIs. Nevertheless, the XWiki API is powerful enough to allow a wide range of applications to be safely developed, if "the XWiki way" is properly followed.
42 +
43 +Velocity is also available in some other parts of XWiki: it is the language in which all the templates that generate the HTML UI of XWiki, it can be optionally activated in skin extensions, and it is executed when sending CSS and JavaScript skin resources from the filesystem.
44 +
45 +In conclusion, **Velocity is suited for projects with small to medium complexity, and which don't require access to other resources except the provided XWiki API and registered script services. It allows very quick and easy development, offers good security and decent performance, and can easily be packaged and distributed as a XAR.**
46 +
47 +== Groovy ==
48 +
49 +Groovy is a full-fledged scripting language, which supports almost the entire Java syntax, and provides its own syntax delicacies and custom APIs that enhance the Java language even further. While it is recommended that complex code be written in Java as components accessible via script services, Groovy has the advantage that it is written live in the wiki, without requiring compilation, deployment and server restarts, thus enabling faster development.
50 +
51 +The XWiki API is available in the context when executing Groovy scripts, but unlike in Velocity, the code isn't limited to this API, and any other classes or objects can be accessed freely. New classes can be defined in Groovy, compatible with Java classes, and this allows more structured code to be written, unlike in Velocity. A particular case of classes is new component roles and component implementations, which allows, for example, new script services or new event listeners to be defined in the wiki. It is possible to load attached jar files into the classpath of an executing script, which means that a wiki document can contain a complex program AND the required libraries not provided by the platform.
52 +
53 +Other than being available as a scripting language for writing custom code, it is also the language in which scheduler tasks are written.
54 +
55 +In conclusion, **Groovy is suited for complex projects or for custom wiki enhancement through new components, when speedy live development is required. Being written in wiki documents, it can also be easily packaged and distributed as a XAR.**
56 +
39 39  After taking into account these considerations and if requiring Programming Rights isn't an issue for you, you should pick the script language that you're most familiar with!
40 40  
41 41  = XWiki Scripting API =

Get Connected