Monday March 30, 2009
|
Vanity Foul Dedicated to the wanderings of an egotistical mind. |
|
Standalone GORM via Java I spent some time re-jiggering the code, specifically getting Burt's GormHelper to load from the applicationContext.xml. I also pulled the use of domainclasses.txt and listed them directly (I'd rather make the code smarter and have it load anything with the @Entity annotation - but that's beyond the current exercise). Don't forget to change the base-package in the gorm:sessionFactory bean.
<bean id="gormHelper" class="com.burtbeckwith.gorm.GormHelper">
<constructor-arg>
<list>
<value>com.brainopolis.GormAuthor</value>
<value>com.brainopolis.GormBook</value>
</list>
</constructor-arg>
</bean>
I've got a simple GormProxy for a few dynamic GORM methods - save(), findBy() - but you'd probably want to build a proper Interface for the GORM classes to extend. I've built a small demonstration app, complete with new GormHelper, applicationContext.xml, and a couple Test Cases.
Using GORM from Java As the advocate of GORM, it fell to me to prove that it was possible to use GORM from within a Java application. I knew, theoritically, that is was possible, but it took me a couple days to prove it. The few related links I could find were all pre-Grails 1.1, and most were over a year old. Still, based on the shoulders of the giants who went before me, I was able to get it working. Here is the list of Giants, and the pages the left behind to guide me:
(
Mar 27 2009, 01:27:54 PM
)
Groovy n Grails
Permalink
Parrot 1.0 It's been a long time coming, Parrot 1.0 is finally released. How far behind is Perl 6? Epoch Time Event Kottke notices that tomorrow, Feb 13th, at 5:31:30 PM Central Time, the unix clock (which some call "epoch time") will hit 1234567890 (that is the number of milliseconds since 'the beginning', Jan 1 1970 iirc). Some coworkers and I are celebrating at Shamrocks, stop on by and join us. Warning: Zombies Ahead lighten up people "oh noes, someone might crashed reading about scary zombies whilst driving!" I think the hazard is minimal to non-existent, and I find it ... interesting that the people interviewed are so worked up. Or perhaps the TV station only showed those who were upset, and not the interviewees ROFLMAO? Re: Re: Grails Testing Fixtures I edited the Fixtures plugin: class FixtureLoader implements ApplicationContextAware {
def classLoader
ApplicationContext applicationContext
def createBuilder() {
new FixtureBuilder(applicationContext, classLoader)
}
void load(String[] fixtures) {
def bb = createBuilder()
fixtures.each {
bb.loadBeans("/fixtures/${it}.groovy")
}
applicationContext = bb.createApplicationContext()
}
void load(Closure beans) {
def bb = createBuilder()
bb.beans(beans)
applicationContext = bb.createApplicationContext()
}
Object getProperty(String name) {
if (applicationContext.getProperty(name)) {
return applicationContext.getProperty(name)
}
return super.getProperty(name)
}
}
This doesn't completely fix my complaints, but now I've direct access to the object created in the fixture:
fixtureLoader.load("testing")
def fooInstance = fixtureLoader.foo1
def barInstance = fixtureLoader.bar1
I still have the instantiation/relationship issues, but that's due to Spring's BeanBuilder, not the Fixture plugin itself. Perhaps I'll look into what it would take to fix that as well. Re: Grails Test Fixtures I'm less happy with Grails Test Fixtures plugin today, as I discovered that it won't do both sides of a relationship properly. If I've got class Foo which hasMany Bar's, and Bar belongsTo Foo:
testing.groovy
beans {
foo1(Foo) {
name = "foobar"
bars = [/* FAILS -> ref(bar1) */]
}
bar1(Bar) {
name = "barbaz"
foo = foo1
}
}
I can't say bars = [bar1] because bar1 won't have been instantiated yet. Even trying to use the "deferred" object references fails. And I cannot declare bar1 first, because it won't be able to set it's foo property and will fail to save. So
fixtureLoader.load("testing")
def foo1 = Foo.findByName("foobar")
// foo1.bars will be empty
def bar1 = Bar.findByName("barbaz")
foo1.bars = [bar1]
// now I can start testing
Which brings me to another point: Ruby fixtures would expose foo1 and bar1 as instances for me to use, no lookup necessary (as I understand it). Maybe I'm not doing it right? Will they be there in Grails Fixtures if I use the Spring Application Context? Re: What GOP Leaders deem wasteful in Senate stimulus bill From CNN: "On Monday, House Republican leaders put out a list of what they call wasteful provisions in the Senate version of the nearly $900 billion stimulus bill that is being debated". I have to agree that several of these are questionable, others are defensible with "economic stimulation" in mind.
It's really tempting to comment on every line item, but I've tried to restrain myself. |
|
||||