BlackBox : Tag chama

MetaClass/Delegate warning

Warner Onstine — Mon, 04 Jun 2007 20:32:22 -0700

I’ve been working like a fiend on Chama and am just about ready for an alpha release (not much but will have some basic model and dao creation from a groovy dsl paired with database goodness). Like a good programmer I have been building stuff up in chunks so that I can test everything separately and now this morning I started finally integrating everything together and blammo! something strange was happening.

The first part of this puzzle lies in QueryBuilder.groovy, this class is a builder that eventually will get called from inside of a finder method (like findAll()) and get parsed by another meta class, but more on that in a minute. Inside of QueryBuilder I do some checks on whether we are passing a closure or not, if we are then I set the delegate class to the current QueryBuilder instance and call the closure. Thus, when the closure continues processing the next interior method of the closure gets called it calls the QueryBuilder again allowing me to create new restrictions inside the current criteria. Running my tests and everything works as expected. Now for the strange part.

In the next part I created a new class JavaModelDAOBuilder.groovy which will actually parse a Groovy script and call each method in turn through a custom meta class called MethodInterceptor. This meta class has now essentially taken first responder position to any method calls that happen on the Groovy script. Which actually sounds good on the surface, until I discovered that a closure is actually “owned” by its class. Now that the class has a meta class it will intercept all calls to the closure, completely bypassing the delegate.

After some digging I can see how this makes sense and after sending a message to the list I got some great responses. The final solution that Jochen(Blackdrag) came up with is to set a flag so that meta classes can “delegate” to another delegate. I think that this is definitely a workable solution, but for now I have some kind of hacky solution in the MethodInterceptor so that it looks for anything that the delegate should actually be handling and pass it back to that instance.

The good news is that it looks like this will be fixed in the near future, for those of us really pushing Groovy’s Meta Object Programming (MOP) and I think I’m going to be joining the dev list so that I can watch those conversations (especially the MOP-related ones). On another note I’m working on a few more Meta-related posts that will hopefully be of interest to some people ;-).

First Maven plugin

Warner Onstine — Thu, 21 Dec 2006 22:04:27 -0700

I’ve been working on Chama recently and have been making some good progress. One of the last big hurdles before getting all of the Model, View, Controller generation working has been:

Connecting to a database and gathering metadata - 90% complete (just have the relationship, primary key, foreign key stuff to work out)
Getting Chama packaged up as a real distributable app that you can download and get up and going quickly

Rather than go through a whole bunch of Ant copy scripts and integrating that with my Maven build I decided to write a plugin that would copy everything over into a specific directory structure and zip up for me (and I can also add in the tar.gz stuff real easy now too). I gotta say it wasn’t too difficult, although the docs leave a lot to be desired in this department. With all the plugins out there you would think this would be more fleshed out, especially since they want everyone to move away from the old Jelly scripts that people wrote in Maven 1. Anyways, it’s fairly simple to do with some caveats.

There appear to be no docs on what all the custom expressions are such as:
- expression="${project}"
- expression="${project.build.directory}"
- expression="${component.org.codehaus.plexus.archiver.manager.ArchiverManager}"
Or if you can actually use expressions like these when setting default values of properties (you can, at least that’s what I’ve gathered by looking at other plugins)
And if you do or do not need to have getters and setters for your variables that you’ve “annotated” (I say that in quotes because it doesn’t act like true annotations, or at least there isn’t a package in Maven called annotations where you can find docs on all of these)
- My assumption is that at least the setters are necessary so that it can use those to populate the variables you want Maven to populate your plugin with)

All that said it was mostly easy to write my little packaging plugin as I was willing to dig through the source code of some of the existing plugins that were doing similar things (maven-assembly-plugin and maven-war-plugin). That isn’t to say that I’m 100% sure I understand exactly how everything works (good idea but not 100% ;-).

If I get a chance I’ll see if I can contribute something a little more to the plugin docs than what is there currently because others shouldn’t have to do what I did to get through this and it isn’t that difficult once you know the secret handshake.

New project "Chama"

Warner Onstine — Thu, 07 Dec 2006 22:50:00 -0700

So, where has all this DSL stuff been leading? One of my projects that has been sitting on the back-burner for a while has been Chama. Chama was born out of the frustration of writing the same boiler-plate code over and over for database-backed sites that are run on Tapestry. While you can certainly use something like Trails I was not happy with the additional amount of configuration I needed to do in order to get the forms to look and behave the way I wanted them to.

Why not use Ruby on Rails then, or even Grails if I want to stick with the Java theme?

A variety of reasons:

I'm familiar with Tapestry, Hibernate, etc.
I'm very familiar with Java
I want to learn Groovy as a language
I don't want to switch out my deployment options to have to deal with deploying my apps to a new server and having to configure it all over again so that it'll run RoR
I like generators ;-), no really this is an exercise that I want to undertake and if others find value in it that's great
Mostly to make it easier for me to get some app ideas I've had off of the ground

What will Chama use:

Groovy as the primary language, with some Java thrown in where needed
Most likely Yaml for configuration with JYaml for dealing with it
Quite possibly several DSLs for each area (Model, View, Controller)

I don't know yet exactly how far I'm going to take Chama, mostly I just want to get a tool together that will help me build stuff. If others find value in it and it gets extended from there and heads in a direction I never thought about, great! All the code will be available under an Apache License once I start working on stuff. I have some tentative dates setup in my Trac instance (what?! using Python for a Java app?). Comments are welcome, and I will use this blog to announce releases as they happen, the first milestone is set for 12/22/06 (oops was tomorrow, moving to two weeks, wow it's been two weeks since I first set this up already).