Quantcast

combining a plug-in for Grails and Griffon?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

combining a plug-in for Grails and Griffon?

Alan Bowsher-2
We have a scenario where we'd like to use a domain model in two contexts - one web, one a swing app (so that the two apps share validation logic).  

I had assumed that Griffon, coming from the Grails ecosystem, used the same mechanism, and this would be possible.  However, after a bit of searching, it seems that Griffon does not natively support Gorm, is that correct?

In our existing Swing app, we are using Gorm outside of Grails, so there may be workarounds possible, I was just hoping that converting that app to Griffon would give me an easy way to share the domain model between the two.  

I was hoping that we could just create our own plugin, and use it in both.

First of all, do I understand the limitations correctly, or am I missing something?

Secondly... any advice on a strategy here?

Thanks...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: combining a plug-in for Grails and Griffon?

pledbrook
> We have a scenario where we'd like to use a domain model in two contexts -
> one web, one a swing app (so that the two apps share validation logic).
>
> I had assumed that Griffon, coming from the Grails ecosystem, used the same
> mechanism, and this would be possible.  However, after a bit of searching,
> it seems that Griffon does not natively support Gorm, is that correct?

Right. I think this is a long-running feature request.

> I was hoping that we could just create our own plugin, and use it in both.
>
> First of all, do I understand the limitations correctly, or am I missing
> something?

I would ping Andres Almiray, project lead for Griffon. He's in a
better position to answer these questions. One issue is that GORM
outside of Grails is currently tricky with Grails 2. The other is that
Grails and Griffon plugins have different structures. But it
definitely sounds like a worthwhile project.

Peter

--
Peter Ledbrook
Grails Advocate
SpringSource - A Division of VMware

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: combining a plug-in for Grails and Griffon?

aalmiray
In reply to this post by Alan Bowsher-2
Alan Bowsher-2 wrote
We have a scenario where we'd like to use a domain model in two contexts -
one web, one a swing app (so that the two apps share validation logic).

I had assumed that Griffon, coming from the Grails ecosystem, used the same
mechanism, and this would be possible.  However, after a bit of searching,
it seems that Griffon does not natively support Gorm, is that correct?
Yes, this is a correct assumption. In its current incarnation GORM relies on some Grails specific classes that Griffon does not provide.

Alan Bowsher-2 wrote
In our existing Swing app, we are using Gorm outside of Grails, so there
may be workarounds possible, I was just hoping that converting that app to
Griffon would give me an easy way to share the domain model between the
two.

I was hoping that we could just create our own plugin, and use it in both.

First of all, do I understand the limitations correctly, or am I missing
something?

Secondly... any advice on a strategy here?

Thanks...
As Peter notes, Grails and Griffon plugins may look similar but they have different implementation strategies. For one, Griffon runtime plugins are separated from buildtime plugins (Grails supports both modes with a single plugin descriptor). Also, Griffon plugins are delievered in binary form since the early days while Grails just gained that ability recently, still source form is the default way.

Now, sharing code between Grails and Griffon is possible provided you do it with an intermediate project that packages the classes in a jar, effectively making this project a shared library between Grails and Griffon. Grails 2.0 supports SNAPSHOT releases while Griffon 0.9.5 (soon to be released) will add that feature.

I believe it may be possible to invoke the new AST transformations on domain classes if the project is a standalone one. Now, as you say, you've been able to run GORM in standalone mode, maybe there's a chance to turn that code into a Griffon plugin :-)

Cheers,
Andres
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: combining a plug-in for Grails and Griffon?

Alan Bowsher-2
Thanks for the replies.

Our current batch tool doesn't use Griffon (sorry, it was version 0.1 when we started coding).  However, we did borrow a snippet of code from one of the Griffon examples to use GORM, so thanks for that ;-)  See below.  If we stay with the batch approach, it might make sense to switch to Griffon.  We are considering changing the batch app to a web app, in part to make some of these issues easier, but haven't decided yet.

We have at minimum 2 web apps that share this code as well.  So I was hoping to use the Plugin mechanism to share all types of resources, not just a jar file for classes.

We don't currently use Maven, so I would probably use the simplest strategy possible to share the Plugin.  Nothing against Maven, I just don't want to take the time to learn it for this.  It looks like we could either use a shared directory, or add a Custom Resolver of some sort.

So I guess if we wanted to do what you are suggesting (share a jar file also), in our project that builds the Plugin, we'd both distribute the whole Plugin via package-plugin, and also have some sort of Ant task or whatnot to also build a jar file and distribute it for the batch app?

One other issue we have that I did not mention before - we want to share the domain validation logic, but there are some slight differences that are context-sensitive.  In the web-apps, we can use a Spring-injected request-scoped bean in the domain objects, to indicate to the custom constraints what the context is (i.e. which module of the app the user is currently in).  But a request-scoped bean won't work in a batch app (from the Spring docs, I believe it would throw an exception).  Since the code is shared, we need some other approach that works in both situations - possibly a custom scope that knows whether it's in a web-app or batch app or some such thing?  Or maybe, given your suggestion of a shared jar file, we just wouldn't use spring/resources.groovy in the jar file for the batch app, and so could configure the bean differently for the batch app (singleton would be fine there). 

If it's useful, here's a quasi-cleaned up version of what we do in our current batch application (essentially borrows from an early Griffon sample, I'm sure you've seen this before):

       def bb = new grails.spring.BeanBuilder()

        bb.loadBeans new ByteArrayResource("""
import org.springframework.context.support.StaticMessageSource
import org.apache.commons.dbcp.BasicDataSource

beans {

messageSource(StaticMessageSource)
dataSource(BasicDataSource) {
driverClassName = 'org.hsqldb.jdbcDriver'
url = 'jdbc:hsqldb:mem:batDB'
username = 'sa'
password = ''
}
gorm.sessionFactory('data-source-ref':'dataSource', 'base-package':'com.<mycompany>.<myproject>', 'message-source-ref':'messageSource') {
hibernateProperties = ['hibernate.hbm2ddl.auto':'create']
}          
}
        """.bytes)

        context = (GrailsApplicationContext)bb.createApplicationContext()

Thanks

On Tue, Jan 31, 2012 at 9:32 AM, aalmiray <[hidden email]> wrote:

Alan Bowsher-2 wrote
>
> We have a scenario where we'd like to use a domain model in two contexts -
> one web, one a swing app (so that the two apps share validation logic).
>
> I had assumed that Griffon, coming from the Grails ecosystem, used the
> same
> mechanism, and this would be possible.  However, after a bit of searching,
> it seems that Griffon does not natively support Gorm, is that correct?
>
Yes, this is a correct assumption. In its current incarnation GORM relies on
some Grails specific classes that Griffon does not provide.


Alan Bowsher-2 wrote
>
> In our existing Swing app, we are using Gorm outside of Grails, so there
> may be workarounds possible, I was just hoping that converting that app to
> Griffon would give me an easy way to share the domain model between the
> two.
>
> I was hoping that we could just create our own plugin, and use it in both.
>
> First of all, do I understand the limitations correctly, or am I missing
> something?
>
> Secondly... any advice on a strategy here?
>
> Thanks...
>
As Peter notes, Grails and Griffon plugins may look similar but they have
different implementation strategies. For one, Griffon runtime plugins are
separated from buildtime plugins (Grails supports both modes with a single
plugin descriptor). Also, Griffon plugins are delievered in binary form
since the early days while Grails just gained that ability recently, still
source form is the default way.

Now, sharing code between Grails and Griffon is possible provided you do it
with an intermediate project that packages the classes in a jar, effectively
making this project a shared library between Grails and Griffon. Grails 2.0
supports SNAPSHOT releases while Griffon 0.9.5 (soon to be released) will
add that feature.

I believe it may be possible to invoke the new AST transformations on domain
classes if the project is a standalone one. Now, as you say, you've been
able to run GORM in standalone mode, maybe there's a chance to turn that
code into a Griffon plugin :-)

Cheers,
Andres


--
View this message in context: http://grails.1312388.n4.nabble.com/combining-a-plug-in-for-Grails-and-Griffon-tp4341411p4344675.html
Sent from the Grails - user mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Loading...