Tug Wilson

Paul King has done a great article on the Wiki which gives you a very good introduction to XML processing in Groovy http://docs.codehaus.org/display/GROOVY/Processing+XML

MarkupBuilder does not generate XML declarations, comments or handle mixed content.

StreamingMarkupBuilder does not put any characters in the document unless you tell it to - hence it is not inserting newlines.

If you want break the lines then you can just add
out << "\n"
lines.

import groovy.xml.StreamingMarkupBuilder def mb = new StreamingMarkupBuilder() mb.encoding = "UTF-8" def doc = mb.bind { mkp.xmlDeclaration() comment << "comment here" root{ level1{ out << "value" level2() level2() } level1(name:"name1"){ level2(name:"name2") } } } System.out << doc

Note: You generally would not explicitly set the encoding. StreamingMarkupBuilder will examine the encoding used by the Writer it's being written to and sets the encoding accordingly. If it can't determine the encoding it will use US-ASCII.

also the out << ans comment << notation has only recently been introduced for the 1.0 release. If you are using and older version then you need to do this:
import groovy.xml.StreamingMarkupBuilder def mb = new StreamingMarkupBuilder() mb.encoding = "UTF-8" def doc = mb.bind { mkp.comment "comment here" root{ level1{ mkp.yield "value" level2() level2() } level1(name:"name1"){ level2(name:"name2") } } } System.out << doc

This notation will work with both older versions of Groovy and 1.0 - older versions are not able to emit XML declarations, though

I'm afraid I can't help you as I'm a Groovy guy not a Grails one

I'd suggest you ask the quetion on the Grails usr mailing list - you should get a pretty rapid response there.

I have made minor changes to the page and have corrected a couple of errors.

I hope you find it clearer now

I think you may be misreading the example.

Groovy properties are declared vert much like fields but they result in private fields and public getters and setters.

I tried your example here and it works just fine (using Clifton's code and changing def to MyInterface).

Varables can be typed (i.e. declared as in Java ) or untyped (declared as def) in Groovy.

Java programers start by decaring everything as typed and then get comfortable with 'def' after a while (and with omitting ';').

Feel free to post any exception you get on the groovy usr list and we'll try and figure out your problem.

You can pre compile everything. You can deploy Groovy apps using only the JRE.

So, theorically I can use Java and Groovy interchangeably ?
Can I use Groovy completely to develope EGB ? (Enterprise GroovyBeans, inspired by Gregg's Gwing )
Or even to develope a framework like Hibernate, Tapestry or Spring ?

Yes - We already have Groovelets (which are Groovy Sevlets) and GSPs (can you guess what they are? )

That is some awesomely concise code considering what it's doing and the code I've written in the past in pure java to do the same thing.

Yes - however, as Ed has pointed out, we can do better that that

Groovy adds lots of extra methods to standard Java classes which add useful functionality. So we have eachDir(), eachFile(), eachFileMatch() and eachFileRecurse(). These all take closures as their last parameter and call the closure with a File object parameter. The eachFileMatch method also takes a regexp to filter the file names.

This means that you can do stuff without all that tedious and error prone boilerplate code.

IDE's can often generate Java boilerplate code with a couple of keystrokes. However, you still have to read and maintain the verbiage. Conciseness of notation as a reading benefit not a writing benefit.

In case you are wondering why your first example desn't complain that listallFiles is not defined...

It never calls listAllFiles recursivly. This is because File.list() returns file names not paths. So you are checking if there is a directory in the current working directory with the same name as a file in /home/ccc/jedit/4.2

You have two problems:

1/ listAllFiles isn't available to the closure as it isn't actually declared until the end of the statement which creates the closure

2/ you pass a File object to the recursive call which is expecting a String

This works:

def listAllFiles listAllFiles = { path -> new File(path).listFiles().each { if(new File(it.toString()).isDirectory()) listAllFiles(it.toString()) else println it } }

Though I think this is slightly nicer
def listAllFiles listAllFiles = {directory -> directory.listFiles().each { if(it.isDirectory()) listAllFiles(it) else println it } } listAllFiles new File('/')

I think 1/ can be considered a bug. If you would be kind enough to raise a JIRA issue on the Groovy site somebody will take a look at it.

list() returns String[]
listFiles() returns File[]

The Strings are file names.

File.toString() is a path.

So you will get differet results

In the first example you don't need it.toString()

In the seccond example you don't need to instantiate the File object

Gecause dynamic languages solve the problem that Java 5 generics attempt yo solve in Java.

We haven't done any benchmarking. However I would expect Groovy to be faster than JRuby today. JRuby is interpreted and we are compiled.

I expect both Groovy and JRuby's performance to improve in the future. We have done very little to optimise performance - we have been getting the subtleties of impedance free interfacing to Java right. The JRuby guys plan to generate bytecodes in the future.

Because Groovy leverages the huge set of Java libraries available you often find that the bulk of the time is spent inside a Java library so the performance of Groovy is not significant.