Damned. You found it. I thought I can trick everybody
In fact I did try the approach with yearlyIncome / 12. Unfortunatly this resulted in a BigDecimal of a different scale, which means they are not equal and my test failed. When using .divide(12) the scale was correct. So I did it this way and hoped that nobody would find out.

Do you have any idea why .divide(12) and /12 behave differently?

To move the address code to another method I would simply refactor it like (Pseudocode follows)

—————————————————
Person transform(File)
{
def xmlData = new XmlSlurper().parse(xml) // only done once

//do the person stuff

Address address = doAdressStuff(xmlData)
person.address = address
// do the rest of the person stuff
return person
}

Address doAddressStuff(xmlData)
{
//do the address stuff like in source example
return address
}
—————————————————

In that example Address is part of the object tree, that needs to be returned. If the transformation ends in more than one root object, we could let transform return a Map instead of the root object.

The parse call to the slurper happens only once in any case.

Yes, I would split the whole method too. I just did not do it for demo purposes. If you want to pass the xml, just pass the xmlData Object. This is just a pointer to the slurper and passing it will not cause any re-read.

The memory issue is interessting. I will have to try it.

I have a litte problem with the sketched solution. From modeling perspective I would create a second tranform method which creates adress objects, so I could maybe create alternate delivery adresses for orders etc. But how to pass the file content to avoid re-reading of the whole stuff? Another method to encapsulate file opening from file processing? I follow strug that one could run into memory issues here.

Regards
Rayk

PS: I really L O V E the free yWorks editor

@strug
The mechanism for export is the XML builder. Pretty elegant too, but may be another article.

As for the memory consumption, I have not tried it myself, but XmlSlurper is supposed to be more memory efficient than normal XML parsers. It uses some lazy initialization and reads only stuff that is asked for by the GPATH expressions.

do you know if there is s.th. similar to export our objects into xml?

do you know if this solution works with very large documents as well? it looks like the xml is loaded into memory as a whole.

one alternative we currently use, using a xsd and generate the java files with jaxb. next, the xml is automatically mapped into these interface objects. next, you need to map from interface object to domain object.