Thanks. Yeah, I'd say it's stable. I have a number of personal apps
that use it, and Mentor (where I work) is using it for a few more,
some in production some not. For the next version I'm cleaning up
some of the internal Hibernate bits and looking at some better
ColdSpring helpers so you can write your singletons in Groovy as well,
but still manage them like any other bean. Right now (with 1.0)
everything is scriptlet focused, which was the original goal. Still
an important one, but there are some advantages to writing entire
classes in Groovy as well as embedding scriptlets into your CFML.
The edges of GORM are kind of blurry. For example, a lot of the
metadata you define in your domain classes is used for both Hibernate
and for the view layer and validation. But that's not really GORM,
it's more Grails as a whole. CFGroovy isn't going to help you with
validation, object binding from request params, scaffolding, etc (as
Grails does), but that's not it's intent. I would be simple to build
some of that (or maybe just hijack it from Grails (who hijacked it
from Spring)), but I've intentionally left the view layer out of the
picture. Different set of problems for a different tool to address.
Dealing with Hibernate is ridiculously simple. Here's how you get a
page from the list of Entries ordered by date:
<cfreturn variables.cfhibernate.getCurrentSession()
.createQuery("from Entry order by createDate desc")
.setFirstResult(offset)
.setMaxResults(limit)
.list() />
If you're in a Groovy context (instead of a CFML one), it'd look like
this (shockingly different!):
return sessionFactory.getCurrentSession()
.createQuery("from Entry order by createDate desc")
.setFirstResult(offset)
.setMaxResults(limit)
.list()
A whole JEE stack is only required if you want more than a web
container. That usually means either EJBs and container-managed
transactions, but the whole premise of Spring it so provide similar
features with core Java (i.e. without JEE). A lot of people (most
people?) use Spring in a web context, but there isn't anything
requirement for running in a web container.
BC's use case is a bit different from what CFGroovy is designed for.
As Marc pointed out, it also wasn't available in any usable form when
they started. I've not seen the insides of BC's stack, but from what
I understand they're using Groovy in a Java context, not a CFML
context, and then putting a CFML layer on top of that Java context.
So while there's interaction between CFML and Groovy, they're on
different layers of the application. CFGroovy is about supplying
Groovy to your CFML layers in a transparent way (the same style as
CFSCRIPT). So even if CFGroovy had been around, I don't know that
there would have been much of a case for them to use it with their
architecture (as I understand it).
As for blogging, I'm working on a more substantial sample app (where
the ColdSpring conf came from) that showcases CFGroovy a bit more.
Once that's done and I'm convinced that all the bugs have been ironed
out I'll make an official 1.0 release.
cheers,
barneyb
On Wed, Feb 11, 2009 at 12:32 PM, Henry Ho <[email protected]> wrote:
> This looks totally amazing! Would you say CFGroovy is at a stable,
> production level yet? What are you planning to do with the next version?
>
> I've read about GORM in Grails. It was meant to provide an easier API than
> Hibernate's, right? Since CFGroovy does not have a GORM-like layer, would
> dealing with Hibernate directly be a nightmare?
>
> This is the first time I saw that ColdSpring configuration. Maybe it
> deserves to be on an entry of your blog?
>
> So under what situation is JEE and whole java stack is required? How come
> the guys at Broadchoice didn't use CFGroovy instead?
>
>
> This is eye-opening to say the least!!!
>
>
> Henry Ho
>
>
> On Wed, Feb 11, 2009 at 12:10 PM, Barney Boisvert <[email protected]>
> wrote:
>>
>> Neither Spring nor Grails requires JEE either, only a web container
>> (what CF/Railo runs in). If you use CFGroovy, it provides the same
>> sort of wrapping of Hibernate that Spring provides, though it's not as
>> full featured. If you need some of the more esoteric functionality
>> you'll have to roll your own to some extent, but for the "mainstream"
>> use cases it's all really simple. I've put some ColdSpring conf for
>> setting up CFGroovy with Hibernate support and a transaction aspect
>> for proxying your services with at the bottom of the email, along with
>> a sample entity POGO. Very Spring-like, very simple.
>>
>> You can certainly write custom SQL code either via Hibernate or just a
>> normal CFQUERY tag against the database directly. CFGroovy uses a
>> standard DSN for it's connection source, so you can use the same DSN
>> in CFQUERY and do whatever you need. You also have access to the full
>> Hibernate query mechanisms, so you can go at it that way as well. You
>> obviously can't use CFQUERY (or any CF tags) inside a POGO, but you
>> can use the @Formula annotation if you need a dynamically computed
>> property that you'd rather express in SQL instead of with Groovy code.
>> If you're willing to break a little encapsulation, you can access the
>> Hibernate session from inside your POGO to run arbitrary queries that
>> way, but I'd strongly recommend against it. If you want to do that,
>> you probably have an architectural/design issue to address.
>>
>> cheers,
>> barneyb
>>
>> Here's the promised ColdSpring config:
>>
>> <bean id="cfgroovy" class="cfgroovy.cfgroovy" init-method="configure">
>> <property name="path">
>> <value>${groovyPath}</value>
>> </property>
>> <property name="plugins">
>> <list>
>> <ref bean="cfhibernate" />
>> </list>
>> </property>
>> </bean>
>>
>> <bean id="cfhibernate" class="cfgroovy.HibernatePlugin">
>> <property name="entityPath">
>> <value>${entityPath}</value>
>> </property>
>> <property name="coldFusionDsn">
>> <value>${datasource}</value>
>> </property>
>> <property name="annotatedClasses">
>> <list>
>> <value>Author</value>
>> <value>Category</value>
>> <value>Comment</value>
>> <value>Entry</value>
>> </list>
>> </property>
>> </bean>
>>
>> <bean id="transactionAdvice"
>> class="cfgroovy.hibernatetransactionadvice">
>> <property name="cfhibernate">
>> <ref bean="cfhibernate" />
>> </property>
>> </bean>
>>
>> And the sample entity POGO:
>>
>> import javax.persistence.*
>> import org.hibernate.annotations.*
>>
>> @Entity
>> class Entry extends AbstractEntity {
>>
>> String title
>> String body
>>
>> @ManyToOne
>> Author author
>>
>> @OneToMany(mappedBy="entry")
>> @Sort(type=SortType.NATURAL)
>> SortedSet<Comment> comments
>>
>> @ManyToMany(mappedBy="entries")
>> @Sort(type=SortType.NATURAL)
>> SortedSet<Category> categories
>>
>> }
>>
>> On Wed, Feb 11, 2009 at 12:00 PM, Henry Ho <[email protected]> wrote:
>> > Oh, right...
>> >
>> > Hibernate+Groovy, w/ CFGroovy, CF8 Standard is okay.
>> >
>> > It is Spring (& Grails I suppose) that requires JEE server, right?
>> >
>> > I thought Spring, in some way, makes Hibernate easy. If I use Groovy
>> > directly with Hibernate using CFGroovy, what sort of difficulties will I
>> > face by using it directly without Spring?
>> >
>> > I guess if I choose that route, I'll write the beans as POGO, use
>> > annotation
>> > for Hibernate, right? What if I need to write some custom SQL code? I
>> > can't use CFQuery in POGO right?
>> >
>> >
>> > Thanks,
>> > Henry Ho
>> >
>>
>>
>>
>> --
>> Barney Boisvert
>> [email protected]
>> http://www.barneyb.com/
>>
>>
>
>
> >
>
--
Barney Boisvert
[email protected]
http://www.barneyb.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---
