The key turned out to be the discovery of the DefaultGrailsDomainClass . This class performs a series of introspections on your domain objects, and allows you to programmatically access quite a bit of information on them. For example, suppose we had the following domain object:

class Pizza{

String name

BigDecimal diameter

List toppings

hasMany = [toppings:Topping]

}

Class ‘Pizza’ contains a name / description, diameter, and a many-to-many relationship with the ‘Topping’ class (although not defined here). Nice and simple… now, the good stuff.

By passing a Domain Object class to DefaultGrailsDomainClass, we can access a good deal of info about that Domain Object. Among other things there are methods to access a Map of the constraints, determine whether or not a property is a relation (1:1,1:m,m:m), and access the properties directly by obtaining a set of GrailsDomainClassProperties . Of particular use to me is the DefaultGrailsDomainClass.getPersistantProperties() method, which returns a GrailsDomainClassProperty List of all the properties that are persisted to the database. That’s pretty excellent.

To illustrate this, let’s get the persistent properties for a Pizza:

pizzaProperties now contains a list of ‘DefaultGrailsDomainClassProperty’ objects. If we iterate through them, we can see the following information:

Think of the possibilities of what can be accomplished by programmatically accessing the properties on your domain object! However, I am not exceedingly clever:

else{//do something clever!}

}

}

The exportClassSingle method above accepts the ConfigObject which will be populated with the domain object’s data, the name of the class, and an instance of the domain object. It is relatively simple: it takes the class, loads its persistent properties, loops through through them and if the property is not an association, it is added to the config object.  By repeatedly calling the method for each of our Domain objects, we build up the ConfigObject which contains class and instance data. The preExportClean() method looks for and escapes any usage of ‘$’, which can cause some odd behavior if not escaped. We ignore associations here because in the real app, everything is connected to one root object; if there were associations among the child objects that we wished to capture then the above method would be quite different.

Given the following DSL:

pizza{

pizza_0{

name="Small"

diameter="8.0"

}

pizza_1{

name="Medium"

diameter="14.5"

}

pizza_2{

name="Large"

diameter="21.0"

}

}

and assuming it’s saved in a String called ‘pizzaDSL’, we can import this data into our system using the following steps:

ConfigObject config = new ConfigSlurper().parse( pizzaDSL )

The ConfigObject config now contains a map of ConfigObjects. Using the key of ‘pizza’ returns a map of 3 more ConfigObjects.

2. Construct objects using the configObject.

config["pizza"].each{key,map->

Pizza p = new Pizza()

p.properties = map

//set toppings

p.save()

}

3. Celebrate

Well, that’s it. I hope this helps explain the usage of the Default Domain Class and that you all find a usage for it.

In turn, I hope to encourage the use of my current favorite language, Python (see http://www.diveintopython.org/ for a good tutorial). For an interpreted language (it does compile to c byte code at runtime), its capabilities and community support are overwhelmingly substantial. I’m continually surprised as I discover more; its breadth is so great, that Python leaves itself open to satire ( also: here and here). I could drone on,  evangelizing its advantages at some detail (and bore everyone to tears, I’m sure), but that’s not why I’m writing today. No, the point here is to give a quick presentation on a particular package I’ve just started using that amazes me, and it should get more use: wxPython.

WxPython is module for Python that is essentially a wrapper for an open source project called wxWidgets, so most of the credit should go to them. WxWidgets is certainly widely used (link: http://wxwidgets.org/about/users.htm ); it’s a package that allows developers to quickly and easily access the GUI components in Windows, OS X, and various flavors of Linux. This allows development of applications that look native to the OS. WxPython allows one to rapidly develop applications entirely in Python, that look native to the OS. Imagine writing an application in OS X, then moving the code to a Windows or Ubuntu machine and having it work and look perfectly without any modifications! No more dealing with .dlls or compiling on individual machines.. just ‘python <appname>.py’.

In practice, it’s surprisingly easily to generate an entire event-driven application. The basic order of implementation is (1) design layout of your buttons,menus, widgets, etc, (2) implement event handlers, (3) bind event listeners to buttons / actions. I’d post some of my code, but it’s almost all currently in an NDA’ed project, so instead here’s some sample code from http://wiki.wxpython.org/AnotherTutorial that creates a program with a toolbar:

#!/usr/bin/python

# toolbar.py

import wx

class MyToolBar(wx.Frame):

def __init__(self, parent, id, title):

wx.Frame.__init__(self, parent, id, title, wx.DefaultPosition, wx.Size(350, 250))

vbox = wx.BoxSizer(wx.VERTICAL)

toolbar = wx.ToolBar(self, -1, style=wx.TB_HORIZONTAL | wx.NO_BORDER)

toolbar.AddSimpleTool(1, wx.Image(’stock_new.png’, wx.BITMAP_TYPE_PNG).ConvertToBitmap(), ‘New’, ”)

toolbar.AddSimpleTool(2, wx.Image(’stock_open.png’, wx.BITMAP_TYPE_PNG).ConvertToBitmap(), ‘Open’, ”)

toolbar.AddSimpleTool(3, wx.Image(’stock_save.png’, wx.BITMAP_TYPE_PNG).ConvertToBitmap(), ‘Save’, ”)

toolbar.AddSeparator()

toolbar.AddSimpleTool(4, wx.Image(’stock_exit.png’, wx.BITMAP_TYPE_PNG).ConvertToBitmap(), ‘Exit’, ”)

toolbar.Realize()

vbox.Add(toolbar, 0, border=5)

self.SetSizer(vbox)

self.statusbar = self.CreateStatusBar()

self.Centre()

self.Bind(wx.EVT_TOOL, self.OnNew, id=1)

self.Bind(wx.EVT_TOOL, self.OnOpen, id=2)

self.Bind(wx.EVT_TOOL, self.OnSave, id=3)

self.Bind(wx.EVT_TOOL, self.OnExit, id=4)

def OnNew(self, event):

self.statusbar.SetStatusText(‘New Command’)

def OnOpen(self, event):

self.statusbar.SetStatusText(‘Open Command’)

def OnSave(self, event):

self.statusbar.SetStatusText(‘Save Command’)

def OnExit(self, event):

self.Close()

class MyApp(wx.App):

def OnInit(self):

frame = MyToolBar(None, -1, ‘toolbar.py’)

frame.Show(True)

return True

app = MyApp(0)

app.MainLoop()

results in this (on Ubuntu):

Resulting application in Ubuntu

While not much to look at, certainly, briefly think about what’s going on here. In ~45 lines of code, we have a fully functional application. It doesn’t do much,  yet, but imagine what we could do if you started hooking up some of your existing Python code, or hooking in some other Python modules. There’s a lot of power in this; the mind can hardly grasp the possibilities of, say, Windows apps powered by Python (take that, Visual Studio). I feel strongly that it has the potential to handle some serious projects, if given the opportunity.

This would be intensive, but I’m still learning wxPython myself. So far, it’s been great fun, and I highly recommend others to check it out. I’d love to see some examples out there of anyone who’s developed apps in the framework (a quick search doesn’t reveal much), and perhaps I’ll post some of my own as I start using it more.

Until then, try taking a look at wxPython.org (link) and the wxPython wiki (link). Give it a shot; I’m sure you’ll love it.