We've Got a Groovy Kind of Editor

Some fun. I seem to have made a Groovy kind of editor... It has a 'Source' view and a 'Console' view. All of it is built on top of the Manifest Multiview sample, which illustrates one of the chapters in the forthcoming NetBeans Platform book. It does not use the unstable XML Multiview API, but just the standard one that's been in the NetBeans Platform forever. Below is my new Groovy editor in NetBeans IDE, with code that comes from Getting to Know Groovy, which I have found to be a very useful article. (This editor is just a draft, by the way. Not all the tokens are colored, and not all tokens are correctly colored, as explained later in this blog entry.)

Above, the "Source" and "Console" are buttons for toggling between the two views. The "File", "Edit, "Actions", and "Help" are the menus from the Groovy Console. (More about that, especially for NetBeans purists who don't agree with having these menu items in the visual view, further on in this blog entry.)

The two sides are synchronized, so that changes made on one side are set to the other side, in the componentActivated() method on both sides. (Some kind of 'Save' action needs to be added, so that the user can choose whether to synchronize the two sides.) However, the synchronization is handy, because it means the user can use the Source view for typing Groovy code, and then use the Console view for testing it!

Quickly looking under the hood, for those who might be interested, the synchronization approach is really simple. This is code in the source view's definition, which checks to see if the Groovy Console (i.e., the visual view embeds the Groovy Console) was started ("isConsoleRunning" should probably be called "wasConsoleStarted", because it is exited after it is started, as explained in recent blog entries), and then retrieves the content of the input area, pasting it into the NetBeans editor (thanks to a recent discussion on dev@openide.netbeans.org, I now know how to replace Registry.getMostActiveComponent(), as shown below):

public void componentActivated() {


    String inputFromVisual = null;

    //First check that the console is running,
    //which implies the the Console view has been opened
    //at least once:
    if (GroovyVisualView.isconsoleRunninng()) {

        //Get the text from the Groovy Console's input area:
        inputFromVisual = GroovyVisualView.getConsole().getInputArea().getText();

        //Next, check that there is actually something in the input area:
        if (!(inputFromVisual.equals(""))) {

            //Get the current NetBeans document:
            JEditorPane [] jeps = Utilities.actionsGlobalContext().lookup(EditorCookie.class).getOpenedPanes();
            for (int i = 0; i < jeps.length; i++) {
                JEditorPane jEditorPane = jeps[0];
                //Set the text of the current document to the Groovy Console's input area:




In addition, notice that the Source view has some syntax coloring. (It would be nice if the Console view's input area had the same syntax coloring, but that would mean rewriting the Groovy Console, or implementing my own, because the current input area is a JTextArea, which means I can't set a MIME type. Pity it isn't a JEditorPane or JTextPane, like the output area.) That's based on the Groovy.nbs file in the NetBeans sources, to which I added new tokens for Swing components in Groovy. Can anyone give me a COMPLETE list of Swing components in Groovy (such as "menuItem" and "panel" and so on)? Currently, notice that I haven't identified all the tokens yet (which is why I'm appealing for a complete list here), as a result of which Swing components such as "menuBar" are not colored in the illustration above. So, I need all the Groovy tokens (as well as as much of the grammar as possible), please... otherwise this Groovy editor will not be so groovy. The full impact of Schliemann can only be felt once all the tokens are filled out completely, then code completion, code folding and all the other features can be added without much problem.

All of this probably looks a lot more impressive than it really is to implement it. Each part of it is very trivial. NetBeans purists might argue that the Console's menu bar should not be displayed in the visual view. Instead, the menu items should be migrated to the NetBeans IDE's menu items. Well, I disagree, and here's why... in NetBeans 6, with the undocking functionality, one will be able to undock each of the Groovy documents (and any other documents) from the IDE, so that, for example, this effect results:

Here, doesn't it make sense that the menu bar is in the visual view? This way, I could be working on multiple Groovy documents simultaneously, potentially spread across multiple monitors. The more control I have localized to the document, the more sense it makes to undock my document.

Anyway, there's a lot more to be said about all of the above, but clearly... we've got a Groovy kind of editor. By the way, the same editor infrastructure (i.e., this multiview editor) could be used for any scripting language, if it has some kind of console or other visual view. A simple check could be done on the MIME type, and then, depending on the MIME type, the applicable visual view could be loaded on the visual side of the editor.

This is the only Groovy-specific part in the editor, on the visual side, for loading the console into the visual area and the menu bar into the toolbar:

public MultiViewElement createElement() {

    Binding bind = new Binding();
    console = new Console(this.getClass().getClassLoader(),bind);
    consoleRunninng = true;

    container = console.getFrame().getContentPane();
    menubar = console.getFrame().getJMenuBar();


    return this;


public JComponent getVisualRepresentation() {
    return (JComponent) container;

public JComponent getToolbarRepresentation() {
    return menubar;

So, in the methods above, we could check the MIME type and load other stuff into the visual view, depending on the language that we're dealing with. Therefore, this isn't just a Groovy editor, but potentially useful for other languages with a console (or something similar) as well.


you can still do console.getInputArea() and console.setInputArea(JTextArea). For example you could use a dummy JTextArea here and just output the text to it. You then display your own component with syntax highliting. You could for example mirror every text change in your editor part in the inputArea and all problems should be solved.

Posted by Jochen "blackdrag" Theodorou on March 20, 2007 at 10:55 PM PDT #

For the whole grammar and all the tokens see my comment here: http://blogs.sun.com/geertjan/entry/grails_in_netbeans_ide

Posted by Ramon on March 21, 2007 at 01:18 AM PDT #

Wow, Ramon, I had overlooked that (probably wasn't ready for it, but I am now, believe me). I'll look into it. What problems did you encounter?

Thanks Jochen, I will look into that. It would be very cool to have Schliemann in the input area of the embedded Groovy Console.

Posted by Geertjan on March 21, 2007 at 01:25 AM PDT #

Probably this isn't the most appropriate place to ask this but, is Project Coyote (https://coyote.dev.java.net/) discontinued in favor of Schliemann?

Posted by Tetsuo on March 21, 2007 at 03:02 AM PDT #

From what I've been told, it works for 5.0, but not later than that. It hasn't been 'discontinued in favor of Schliemann'. It just hasn't been kept up to date. Ultimately, what's there will be migrated to Schliemann, I guess. But there's already a basic Groovy.nbs (i.e., the Schliemann format) in the NetBeans sources right now.

Posted by Geertjan on March 21, 2007 at 03:06 AM PDT #

What do you mean by "unstable" in reference to XML Multiview? Can you point me to specific issuezilla reports, or was that just your general impression (or is it merely because the api is still friend classification and not related to code stability?)

Posted by Peter Williams on March 21, 2007 at 09:14 AM PDT #

Your last point sums it up: "the api is still friend classification and not related to code stability".

Posted by Geertjan on March 21, 2007 at 09:17 AM PDT #

I'm just mentioning that Coyote works in NetBeans 5.5 as well. One thing that is different from the work here is that Coyote runs Groovy (using the standard Groovy distribution startup scripts) in an external JVM (which could have it's advantages). One thing that running Groovy inside of the NetBeans JVM is really cool is that it gives you the opportunity to script stuff inside of NetBeans (e.g. learning the NetBeans APIs by creating a Groovy console module and then adding the important NetBeans APIs to the module - you instantly get a console that can script your actual development environment and learn the NetBeans APIs without having to go through the build-deploy cycle...)

Posted by Alex Kotchnev on March 22, 2007 at 09:27 AM PDT #

Thanks Jochen!

Posted by scape on May 01, 2007 at 03:53 PM PDT #

大阪 風俗 東京 風俗 uguisu 断熱 塗料

Posted by scape on July 29, 2007 at 08:42 PM PDT #

<a href="http://www.delihels.com/" target="_blank">デリヘル</a><a href="http://www.deli-tokyo.com/" target="_blank">東京 デリヘル</a><a href="http://www.deli-tachi.com/" target="_blank">立川 デリヘル</a>

Posted by youko on February 17, 2008 at 01:01 PM PST #

<a href =" http://www.deliyoko.com/ " target="_blank">横浜デリヘル</a>
<a href=" http://www.delibuya.com/ " target="_blank">渋谷デリヘル</a>
<a href="http://www.delibukuro.com/ " target="_blank">池袋デリヘル</a>
<a href="http://www.delimachi.com/ " target="_blank">町田デリヘル</a>

Posted by joe on February 17, 2008 at 01:07 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed

Geertjan Wielenga (@geertjanw) is a Principal Product Manager in the Oracle Developer Tools group living & working in Amsterdam. He is a Java technology enthusiast, evangelist, trainer, speaker, and writer. He blogs here daily.

The focus of this blog is mostly on NetBeans (a development tool primarily for Java programmers), with an occasional reference to NetBeans, and sometimes diverging to topics relating to NetBeans. And then there are days when NetBeans is mentioned, just for a change.


« June 2016