// La version française de cet article est là : 5 astuces pour améliorer l’usage de la console de script de Liferay.
// If you use a RSS reader to read this post, please switch to the HTML page to correctly view the code snippets.
Since the release 6.0, Liferay provide a script console integrated into the Control Panel. Very powerful, this tool becomes fast essential for any portal administrator or developer (if you do not still know the script console, have a look on this article by Jeffrey Handa).
During this post, I am going to present you 5 simple tips to take better advantage of the script console.
The following implementation samples are based on the Groovy language, but most of them are applicable with other languages supported by the portal script console.
Tip #1: Use the HTML in your outputs
You need to know that the script console default output is rendered as HTML content. Thus, think to embed HTML markup in your outputs to enjoy rich formatting.
Tip #2: Show up exceptions on user interface
When any exception arises during script execution, the error message is always the same and give no detail about the error. So, you need to access server logs to make a diagnostic.
To show up exception details on the user interface, envelop your whole code with a try/catch block and print the stack trace on the console output (from the catch clause). There is nevertheless a limitation: it doesn’t work for script syntax errors.
Tip #3: Exploit the predefined variables
A script executed from the Control Panel can access the following predefined variables :
userInfo (java.util.Map<String, String>)
When you write your scripts, be aware of possibilities offered by these variables, particularly the
actionRequest variable, useful for a lot of method calls.
Tip #4: Implement a preview mode
The script console not allowing execution rollback, it’s very convenient to set up a preview mode for side-effect scripts (i.e. performing database updates).
Ce mode "preview" consiste à utiliser un flag qui détermine si les les opérations à effets de bord sont exécutées ou non, alors que les données parcourues sont systématiquement tracées. Ceci permet donc de se faire une idée des données impactées par un script avant de faire effectivement les mise à jour en base de données.
This "preview mode" consists in using a flag which determines if the operations with side effects are executed or not, while the visited data are systematically printed. This thus allows to have an outline of the data impacted by the script, before effectively doing updates to database.
Script example :
Tip #5: Plan a file output for "long-running" scripts
When the execution of a script exceeds a certain duration, the console doesn’t respond any more and returns an error, whereas the script can continue its execution and potentially bring to a successful conclusion... But impossible to know the status without the corresponding output!
To by-pass this limitation, you can set up a file output besides the console output, like in the following example:
Once the initial script was executed, it is possible to read the generated file without direct access to the file system, by using a second script:
Note that method based on a dedicated output file is better than using a classic logger because it’s easier to get back the script output data (which would be more difficult to isolate among all portal logs).
And you, do you have some tips about script console that you can share with the community ? Let us know in the comments !