Concept Groovy Support

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.

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.

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 http://wiki.magnolia-cms.com/display/WIKI/Magnolia+Groovy+Scheduler

add support for data module importers

• combine the nice xml support with the builder!

Could you elaborate more on that?

OK, we have a first outcome of this magnolia+groovy integration PoC. Introducing the magnolia-module-groovy, which can be checked out at http://svn.magnolia-cms.com/svn/community/sandbox/magnolia-module-groovy. 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.

Regarding stk models in groovy, I've just found this article which seems quite interesting http://www.ibm.com/developerworks/java/library/j-pg05245/index.html

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.

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 http://n0nick.net/stuff/terminal/ 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.

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.

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.

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.

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