I’m again toying with the idea of traits for Java (or rather Groovy). Just to give you a rough idea if you haven’t heard about this before, think of my Sensei application template:
class Knowledge { Set tags; Knowledge parent; List children; String name; String content; } class Tag { String name; } class Relation { String name; Knowledge from, to;
A most simple model but it contains everything you can encounter in an application: Parent-child/tree structure, 1:N and N:M mappings. Now the idea is to have a way to build a UI and a DB mapping from this code. The idea of traits is to implement real properties in Java.
So instead of fields with primitive types, you have real objects to work with:
assert "name" == Knowledge.name.getName()
These objects exist partially at the class and at the instance level. There is static information at the class level (the name of the property) and there is instance information (the current value). But it should be possible to add more information at both levels. So a DB mapper can add necessary translation information to the class level and a Hibernate mapper can build on top of that.
Oh, I hear you cry “annotations!” But annotations can suck, too. You can’t have smart defaults with annotations. For example, you can’t say “I want all fields called ‘timestamp’ to be mapped with an java.sql.Timestamp
“. You have to add the annotation to each timestamp field. That violates DRY. It quickly gets really bad when you have to do this for several mappers: Database, Hibernate, JPA, the UI, Swing, SWT, GWT. Suddenly, each property would need 10+ annotations!
I think I’ve found a solution which should need relatively few lines of code with Groovy. I’ll let that stew for a couple of days in by subconscious and post another article when it’s well done
Tagged: Database, Groovy, Hibernate, Java, JPA, Sensei, Swing, SWT
![](http://stats.wordpress.com/b.gif?host=blog.pdark.de&blog=6384723&post=641&subd=darkviews&ref=&feed=1)