Page tree
Skip to end of metadata
Go to start of metadata

Your Rating: Results: 1 Star2 Star3 Star4 Star5 Star 142 rates

Implemented in 4.3


Official Documentation Available

This topic is now covered in Groovy module.

Following some ideas

  • store scripts similar to the templates in the templates workspace
    • or extra workspace, or resources?
  • special property to execute on startup
    • can be used for repairing
  • add support for groovy template/paragraph models
    • make properties accessible in freemarker: model.prop
    • one can select the script in the in-place template's dialog?
  • add support for bean notation for content
    • similar to their xml support
    • content.child.@property
  • add handy closure support
    • content.visit(){..}
  • add builder support
  • add scripted commands
    • make sure that they can be used easily in the observation, schedule and workflow module
    • use case example: archive news & events
  • add the groovy servlet to support scripted servlets
  • add support for data module importers
    • combine the nice xml support with the builder!
  • No labels


  1. Why limit to Groovy, when java.script lets you execute scripts in whatever script language provides a ..provider; Groovy has that, but that'd also mean rhino, bsh, and a bunch of others if people would so fancy.

    1. The integration will hopefully be done with java.script anyway, but some of the classes will be very groovy specific (builder, closure support, ...). As far I understand the groovy support can also be integrated on a other level because groovy is based on Java and allows easier integration into Java itself (use a groovy class in Java code for instance).

      I am not against supporting any scripting language and hope we can make that 'puggable' but I really favor groovy more and more the better I understand it.

  2. Adding the GroovyServlet to the servlets filter would be trivial of course and should allow for dynamically plugging code written in groovy into Magnolia as the GroovyServlet would take care of compiling groovy source files into bytecode. This could be nice e.g. when extending STK models and/or templates allowing developers to immediately see the results of their work by cutting down deployment times. One downside I see is that working with a dynamic language you lose all compile-time checks you have with Java along with IDE refactoring capabilities, autocompletion, etc.

  3. add support for bean notation for content

    • similar to their xml support
    • content.child.@property
      add handy closure support
    • {{content.visit()
      Unknown macro: {..}

    These are really groovy language features - in particular, the .@property notation allows to access a Java class field directly (which you can't do in Java).

    add scripted commands

    • make sure that they can be used easily in the observation, schedule and workflow module
    • use case example: archive news & events

    I already did something similar for the groovy scheduler module

    add support for data module importers

    • combine the nice xml support with the builder!

    Could you elaborate more on that?

  4. OK, we have a first outcome of this magnolia+groovy integration PoC. Introducing the magnolia-module-groovy, which can be checked out at This module allows to use . and .@ notation in groovy scripts to navigate a magnolia/jcr repo and access node data in a "groovy" way. For instance you can do:

     import info.magnolia.context.*
     import info.magnolia.module.groovy.*
     hm = MgnlContext.getHierarchyManager("website")
     node = MgnlGroovySupport.getContent(hm, "/demo-project")
     println node.about.history.@abstract

    The object you get from MgnlGroovySupport.getContent(..) implements info.magnolia.cms.core.Content, so apart from having the syntactic sugar for getting nodes and properties, you also have a fully-fledged Content instance to work with in groovy. Next step, which I discussed briefly this morning with Philipp, is to have stk models written in groovy.

    1. Cool stuff. Agility here we come!

      1. I have just one note to make. While I prefer the notation which uses the @ to differentiate between an 'attribute' and a child node we do not make this differentiation in the free marker support.

        To make the groovy support handy for 'templaters' we should align the two syntaxes. The problem is that the @ syntax is kind of groovy common sense.

    2. Here we have a problem, at least with our console. After running a script like the one above, since the console is supposed to keep its context, you would expect to be able to navigate from node downwards as you please. But actually, if you issued a second time the line

       println node.about.history.@abstract

      the result printed at the console would be an empty map!
      The problem is that that kind of dot navigation under the hood makes a query to the jcr repo and, after the first time, the session is closed. The output doesn't show the exception because it is somewhere eaten up by magnolia, it only appears in application logs.

      2010-01-04 10:37:40,852 ERROR info.magnolia.cms.core.DefaultContent             : this session has been closed
      javax.jcr.RepositoryException: this session has been closed
      	at org.apache.jackrabbit.core.SessionImpl.sanityCheck(
      	at org.apache.jackrabbit.core.ItemImpl.sanityCheck(
      	at org.apache.jackrabbit.core.NodeImpl.getNodes(
      	at info.magnolia.cms.core.DefaultContent.getChildContent(
      	at info.magnolia.cms.core.DefaultContent.getChildren(
      1. We normally solve this by using a info.magnolia.cms.util.LazyContentWrapper.

  5. Regarding stk models in groovy, I've just found this article which seems quite interesting

  6. So with the two patches I just added we should have transparent support for groovy at a deeper, system-wide level. Basically you should be able to write your objects (e.g. models) either with java or groovy and have the latter automatically recompiled when the source is changed. Assuming a Maven project layout, your groovy files can be placed under src/main/groovy (see picture below)

    Then, in the AdminCentral, you can refer to your groovy object as any other object written in java (see picture below) - no matter the language it was used to write it, it gets compiled into a standard java class.


    Next step is to add groovy scripts to the resources workspace or their own workspace and give the Magnolia user with the right skills the possibility to creating or editing groovy objects inline and use them immediately bypassing the usual compile/deploy process. Needless to say that this is still very experimental and must be thoroughly tested as it touches some core pieces of the system.

  7. I began to investigate the possibility to have an interactive groovy shell integrated in magnolia which could be useful and even cool. The idea is to issue commands on the client through a UI like this one which is a js based on jquery and send the request via ajax to the server where a groovy.ui.InteractiveShell instance will call the run(..) method and write on the output stream the result of this execution. This output must be somehow given back to the client as a string and shown in the UI.


    1. And now, as a Christmas present from yours truly, in the magnolia-module-groovy we have something incredibly cool and hopefully useful (coolness being much more important than usefulness, of course): introducing the Magnolia Groovy IShell (where IShell stands for Interactive Shell). It's more or less like having the groovy shell which comes with the standard groovy distribution inside Magnolia. As a bonus, we have default imports for some of the most used magnolia packages and server communication with ajax which adds a lot to the coolness factor. If you dont like the icon in the adminCentral menu, I am with you - so please propose a nicer one. Also the  shell color combination can be improved.

      1. Also think of the cool abbreviation the name Magnolia Groovy Interactive Shell lends itself to: MaGIS! Oh wunderbar!

  8. Fixed some issues with safari. It remains a 'cosmetic' issue though: the input field is outlined in spite of all the css tricks with I used. Most important, the shell now keeps its context (the binding in groovy parlance) in session, until you exit the shell or explicitly run the 'clean' command. Before each sending of a command cleaned the groovy context, which wasnt what a user would expect from a scripting shell. I also implemented a rudimentary history navigation between commands but it's still kind of buggy.

    1. Just for the record, the trick to get rid of the outlined border in webkit browsers when an input field has focus is

      input:focus{outline: none;} 

      Perhaps I should add duh!

  9. Nuntio vobis gaudium magnum! Habemus working command history on ff and webkit browsers (safari, chrome)! Doing some javascript hacking after a while made me realize how true is what Douglas Crockford says "Programming in javascript is programming in a hostile environment". For instance, I found out that different browsers fire different events for the same key pressing: up-down arrows in webkit can be caught by onkeyup or onkeydown but not onkeypress which instead works in ff. Still webkit adds its own style to input fields which ff doesnt, etc etc. For these and other amenities I suggest you to visit the aptly named JavaScript Madness website. And of course, in this case, for the sake of my own mental sanity, I pretended that IE did not exist.

    1. More javascript madness. I've just found out that trim() isnt officially a method of the js String object. So far, so good. The problem is that FF and Chrome somehow provide it, so that calling it on a string does not fail on those browsers. Unfortunately, or better I should say, correctly, Safari does not provide this method, so the console was failing on that browser for no apparent reason. Now the call to String#trim() has been replaced with jQuery.trim(String s) which seems to work across all browsers. 

  10. Renamed the Magnolia Groovy Interactive Shell as Magnolia Groovy Interactive Console. I did it to avoid confusion with OpenMind's shell. As a side effect, the acronymous has got even better: MaGIC instead of MaGIS.

    1. If you were to call it Magnolia Interactive Groovy Shell the acronym could be Migros (wink)

      1. guess that the guys at coop would not like it, though (smile)

  11. Just rewrote the core patches; clean up - making sure there are no codestyle changes makes for useable/readable patches.