Dynamic Compilation

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamic Compilation

Lim Chee Kin
Hi,

Given a Grails application have the capability of generate grails artifects such as domain class, controller and gsp view files, is it possible to instruct Groovy compiler and GSP compiler to compile the generated files when the application is running (without restart the application)? Also, the generated module behave like other Grails controllers which user able to access from the index.gsp.

Please advice.

Regards,
Chee Kin
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

ld@ldaley.com

On 06/10/2010, at 8:11 PM, Lim Chee Kin wrote:

> Given a Grails application have the capability of generate grails artifects
> such as domain class, controller and gsp view files, is it possible to
> instruct Groovy compiler and GSP compiler to compile the generated files
> when the application is running (without restart the application)? Also, the
> generated module behave like other Grails controllers which user able to
> access from the index.gsp.

In theory, I believe so yes but it's very likely you'll hit roadblocks in practice.

But you would likely have to address the registration of each kind of artefact individually. For example, there is a lot of registration that is done by the hibernate plugin with the domain classes it finds, so it's not good enough to just add the classes.

If you do try and go down this road, it's likely to be bumpy.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
Hi Luke,

Thanks for writing.

Yes, I think so. How about create dynamic domain class only? I am asking this question related to Grails Form Builder Plugin (which I plan to create one), let's said user can create the form using the plugin, how should the plugin store the form data besides XML? I think it will be good if each form can have it own domain class(es), what do you think?

Regards,
Chee Kin

On Fri, Oct 8, 2010 at 1:06 PM, Luke Daley [via Grails] <[hidden email]> wrote:

On 06/10/2010, at 8:11 PM, Lim Chee Kin wrote:

> Given a Grails application have the capability of generate grails artifects
> such as domain class, controller and gsp view files, is it possible to
> instruct Groovy compiler and GSP compiler to compile the generated files
> when the application is running (without restart the application)? Also, the
> generated module behave like other Grails controllers which user able to
> access from the index.gsp.

In theory, I believe so yes but it's very likely you'll hit roadblocks in practice.

But you would likely have to address the registration of each kind of artefact individually. For example, there is a lot of registration that is done by the hibernate plugin with the domain classes it finds, so it's not good enough to just add the classes.

If you do try and go down this road, it's likely to be bumpy.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





View message @ http://grails.1312388.n4.nabble.com/Dynamic-Compilation-tp2964601p2967867.html
To unsubscribe from Dynamic Compilation, click here.


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Peter Bell-5
A lot of this becomes very use case specific. Generally when I generate web apps I allow someone to describe domain objects, relationships and validation rules first. From there I then allow them to describe types of screen (list, add, edit, delete, view, import, export, report, etc) and (for example) the form has a field list which describes which fields they can see and of those which they can edit (some fields may be read only for some types of screens/users). That then keys off the domain classes, relationships, properties and validations so if you have a rich system with 3-4 different admin screens for different use cases for the same domain classes, you don't repeat the data types, field titles, validations, etc. I then provide the ability to override specific metadata nodes for a given form, so if you want firstName.Caption to be "Enter your first name" instead of "First name" you can override that without having to have more than one description of the User.firstName property.

The challenge is that the trade offs between what you want to generate, what and how you want to customize and how you want to support smart defaults that are easy to override are often a matter of personal taste. I've gone back and forth over the years on a lot of these issues and while I've found a set of heuristics that work for myself and most of my clients, they wouldn't work for the next guy down the street who has different concerns.

Generally that's the issue you can run into with a form builder (which, if you do it right actually becomes an app builder). There are lots of pretty contentious decisions to be made in your modeling languages, and if you try to make everyone happy you end up with too large a grammar and code base to be worthwhile.

Best Wishes,
Peter


On Oct 8, 2010, at 10:31 AM, Lim Chee Kin wrote:

Hi Luke,

Thanks for writing.

Yes, I think so. How about create dynamic domain class only? I am asking this question related to Grails Form Builder Plugin (which I plan to create one), let's said user can create the form using the plugin, how should the plugin store the form data besides XML? I think it will be good if each form can have it own domain class(es), what do you think?

Regards,
Chee Kin

On Fri, Oct 8, 2010 at 1:06 PM, Luke Daley [via Grails] <<a href="x-msg://810/user/SendEmail.jtp?type=node&amp;node=2968419&amp;i=0" target="_top" rel="nofollow">[hidden email]> wrote:

On 06/10/2010, at 8:11 PM, Lim Chee Kin wrote:

> Given a Grails application have the capability of generate grails artifects
> such as domain class, controller and gsp view files, is it possible to
> instruct Groovy compiler and GSP compiler to compile the generated files
> when the application is running (without restart the application)? Also, the
> generated module behave like other Grails controllers which user able to
> access from the index.gsp.

In theory, I believe so yes but it's very likely you'll hit roadblocks in practice.

But you would likely have to address the registration of each kind of artefact individually. For example, there is a lot of registration that is done by the hibernate plugin with the domain classes it finds, so it's not good enough to just add the classes.

If you do try and go down this road, it's likely to be bumpy.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





View message @ http://grails.1312388.n4.nabble.com/Dynamic-Compilation-tp2964601p2967867.html
To unsubscribe from Dynamic Compilation, click here.




View this message in context: Re: Dynamic Compilation
Sent from the Grails - dev mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
Hi Peter.

Thanks for pointing it out. I will take all your advices in design of the form builder plugin.

Yes, it is obvious that the plugin is opinionated, it has no intend and will not able to "make everyone happy".

Regards,
Chee Kin

On Sat, Oct 9, 2010 at 1:23 AM, Peter Bell <[hidden email]> wrote:
A lot of this becomes very use case specific. Generally when I generate web apps I allow someone to describe domain objects, relationships and validation rules first. From there I then allow them to describe types of screen (list, add, edit, delete, view, import, export, report, etc) and (for example) the form has a field list which describes which fields they can see and of those which they can edit (some fields may be read only for some types of screens/users). That then keys off the domain classes, relationships, properties and validations so if you have a rich system with 3-4 different admin screens for different use cases for the same domain classes, you don't repeat the data types, field titles, validations, etc. I then provide the ability to override specific metadata nodes for a given form, so if you want firstName.Caption to be "Enter your first name" instead of "First name" you can override that without having to have more than one description of the User.firstName property.

The challenge is that the trade offs between what you want to generate, what and how you want to customize and how you want to support smart defaults that are easy to override are often a matter of personal taste. I've gone back and forth over the years on a lot of these issues and while I've found a set of heuristics that work for myself and most of my clients, they wouldn't work for the next guy down the street who has different concerns.

Generally that's the issue you can run into with a form builder (which, if you do it right actually becomes an app builder). There are lots of pretty contentious decisions to be made in your modeling languages, and if you try to make everyone happy you end up with too large a grammar and code base to be worthwhile.

Best Wishes,
Peter


On Oct 8, 2010, at 10:31 AM, Lim Chee Kin wrote:

Hi Luke,

Thanks for writing.

Yes, I think so. How about create dynamic domain class only? I am asking this question related to Grails Form Builder Plugin (which I plan to create one), let's said user can create the form using the plugin, how should the plugin store the form data besides XML? I think it will be good if each form can have it own domain class(es), what do you think?

Regards,
Chee Kin

On Fri, Oct 8, 2010 at 1:06 PM, Luke Daley [via Grails] <[hidden email]> wrote:

On 06/10/2010, at 8:11 PM, Lim Chee Kin wrote:

> Given a Grails application have the capability of generate grails artifects
> such as domain class, controller and gsp view files, is it possible to
> instruct Groovy compiler and GSP compiler to compile the generated files
> when the application is running (without restart the application)? Also, the
> generated module behave like other Grails controllers which user able to
> access from the index.gsp.

In theory, I believe so yes but it's very likely you'll hit roadblocks in practice.

But you would likely have to address the registration of each kind of artefact individually. For example, there is a lot of registration that is done by the hibernate plugin with the domain classes it finds, so it's not good enough to just add the classes.

If you do try and go down this road, it's likely to be bumpy.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email





View message @ http://grails.1312388.n4.nabble.com/Dynamic-Compilation-tp2964601p2967867.html
To unsubscribe from Dynamic Compilation, click here.




View this message in context: Re: Dynamic Compilation


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

ld@ldaley.com
In reply to this post by Lim Chee Kin

On 09/10/2010, at 12:31 AM, Lim Chee Kin wrote:

> Hi Luke,
>
> Thanks for writing.
>
> Yes, I think so. How about create dynamic domain class only? I am asking this question related to Grails Form Builder Plugin (which I plan to create one), let's said user can create the form using the plugin, how should the plugin store the form data besides XML? I think it will be good if each form can have it own domain class(es), what do you think?

If it were me, I'd find another way. I'd be very surprised (and impressed) if you were able to create domain classes dynamically at runtime. There is a LOT of bootstrapping and setup that goes into GORM.

I'd be looking at creating a very abstract domain model that can be used to model a data model, which is typically what CMS's like Plone or Joomla do.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
Hi there,

I love GORM a lot and would like to give it a try. Below is some of my findings for Dynamic Domain Class creation:
1. Create a domain class from String text, but I not sure using GrailsAwareClassLoader to parseClass is the correct way (The code is at the end of the message, please advice)
2. Instantiate the domain class bean to Spring ApplicationContext and enhance it like the way show in DomainClassGrailsPlugin.groovy's doWithDynamicMethods.
3. Instantiate HibernateDomainClassValidator for the domain class bean and enhance it like the way show in HibernatePluginSupport.groovy's doWithDynamicMethods
4. How do Hibernate know the new domain class instantiated and create the corresponding schema, by DefaultGrailsDomainConfiguration.addDomainClass? By reading the API doc, I couldn't find any way to access to DefaultGrailsDomainConfiguration, is it possible to get DefaultGrailsDomainConfiguration object?

Did I missed out any important step? Please advice, thanks.

Code of item 1:
==========
        def gcl = new GrailsAwareClassLoader()
        def injector = new DefaultGrailsDomainClassInjector() {
            boolean shouldInject(URL url) { true }
            protected boolean isDomainClass(ClassNode classNode, SourceUnit sourceNode) { true  }
            protected boolean shouldInjectClass(ClassNode classNode) { true }
                }

        gcl.setClassInjectors([injector] as ClassInjector[])

            GrailsDomainClass domainClass = grailsApplication.addArtefact(DomainClassArtefactHandler.TYPE,
        gcl.parseClass("""
package vacationRequest
 
class VacationRequest {
    String employeeName
    Integer numberOfDays
    String vacationDescription
    String approvalRemark
    Boolean resendRequest
    Date dateCreated
    Date lastUpdated
     
  static constraints = {
        employeeName blank:false, size:5..50
        numberOfDays range:1..14
        vacationDescription blank:false, size:5..255
        approvalRemark nullable:true
        resendRequest nullable:true
        dateCreated blank:false
        lastUpdated nullable:true       
    }
}
                """))
        grailsApplication.domainClasses.each {
            println it
        }

Regards,
Chee Kin

On Sat, Oct 9, 2010 at 1:06 PM, Luke Daley <[hidden email]> wrote:

On 09/10/2010, at 12:31 AM, Lim Chee Kin wrote:

> Hi Luke,
>
> Thanks for writing.
>
> Yes, I think so. How about create dynamic domain class only? I am asking this question related to Grails Form Builder Plugin (which I plan to create one), let's said user can create the form using the plugin, how should the plugin store the form data besides XML? I think it will be good if each form can have it own domain class(es), what do you think?

If it were me, I'd find another way. I'd be very surprised (and impressed) if you were able to create domain classes dynamically at runtime. There is a LOT of bootstrapping and setup that goes into GORM.

I'd be looking at creating a very abstract domain model that can be used to model a data model, which is typically what CMS's like Plone or Joomla do.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Jeff Scott Brown
On Mon, Oct 11, 2010 at 4:59 AM, Chee Kin Lim <[hidden email]> wrote:

> Hi there,
>
> I love GORM a lot and would like to give it a try. Below is some of my
> findings for Dynamic Domain Class creation:
> 1. Create a domain class from String text, but I not sure using
> GrailsAwareClassLoader to parseClass is the correct way (The code is at the
> end of the message, please advice)
> 2. Instantiate the domain class bean to Spring ApplicationContext and
> enhance it like the way show in DomainClassGrailsPlugin.groovy's
> doWithDynamicMethods.
> 3. Instantiate HibernateDomainClassValidator for the domain class bean and
> enhance it like the way show in HibernatePluginSupport.groovy's
> doWithDynamicMethods
> 4. How do Hibernate know the new domain class instantiated and create the
> corresponding schema, by DefaultGrailsDomainConfiguration.addDomainClass? By
> reading the API doc, I couldn't find any way to access to
> DefaultGrailsDomainConfiguration, is it possible to get
> DefaultGrailsDomainConfiguration object?
>
> Did I missed out any important step? Please advice, thanks.
>
> Code of item 1:
> ==========
>         def gcl = new GrailsAwareClassLoader()
>         def injector = new DefaultGrailsDomainClassInjector() {
>             boolean shouldInject(URL url) { true }
>             protected boolean isDomainClass(ClassNode classNode, SourceUnit
> sourceNode) { true  }
>             protected boolean shouldInjectClass(ClassNode classNode) { true
> }
>                 }
>
>         gcl.setClassInjectors([injector] as ClassInjector[])
>
>             GrailsDomainClass domainClass =
> grailsApplication.addArtefact(DomainClassArtefactHandler.TYPE,
>         gcl.parseClass("""
> package vacationRequest
>
> class VacationRequest {
>     String employeeName
>     Integer numberOfDays
>     String vacationDescription
>     String approvalRemark
>     Boolean resendRequest
>     Date dateCreated
>     Date lastUpdated
>
>   static constraints = {
>         employeeName blank:false, size:5..50
>         numberOfDays range:1..14
>         vacationDescription blank:false, size:5..255
>         approvalRemark nullable:true
>         resendRequest nullable:true
>         dateCreated blank:false
>         lastUpdated nullable:true
>     }
> }
>                 """))
>         grailsApplication.domainClasses.each {
>             println it
>         }
>
> Regards,
> Chee Kin
>

This really sounds like a suspect thing to be doing at the application
level.  Maybe there are good reasons to do this for your app in
particular but in general this would not be a good idea.

Have you sorted through what you are really trying to accomplish and
made sure that you really do want to be creating domain classes at
runtime?



jb

--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
Hi Jeff,

Thanks for writing.

The requirement of dynamic domain class creation is related to creation of the Grails Form Builder plugin. Let's say user can create the form using browser-based Form Builder, how should the plugin stored data for form defined by user (I means form data like invoice, order, news, etc., not the form meta-data like label, field, field type, etc)? There is two ways in my opinion:
1) Create a generic domain class to store data of all forms
2) Each form have it own domain class(es) to store it's own data. (My preferred option, but seems like not practical as it needs dynamic domain class)

What do you think? You can find out more background information of the
Grails Form Builder plugin at http://grails.1312388.n4.nabble.com/Grails-Form-Builder-Plugin-td2818208.html

You input and feedback is very much appreciated. Thanks.

Regards,
Chee Kin


On Mon, Oct 11, 2010 at 11:13 PM, Jeff Brown <[hidden email]> wrote:
On Mon, Oct 11, 2010 at 4:59 AM, Chee Kin Lim <[hidden email]> wrote:
> Hi there,
>
> I love GORM a lot and would like to give it a try. Below is some of my
> findings for Dynamic Domain Class creation:
> 1. Create a domain class from String text, but I not sure using
> GrailsAwareClassLoader to parseClass is the correct way (The code is at the
> end of the message, please advice)
> 2. Instantiate the domain class bean to Spring ApplicationContext and
> enhance it like the way show in DomainClassGrailsPlugin.groovy's
> doWithDynamicMethods.
> 3. Instantiate HibernateDomainClassValidator for the domain class bean and
> enhance it like the way show in HibernatePluginSupport.groovy's
> doWithDynamicMethods
> 4. How do Hibernate know the new domain class instantiated and create the
> corresponding schema, by DefaultGrailsDomainConfiguration.addDomainClass? By
> reading the API doc, I couldn't find any way to access to
> DefaultGrailsDomainConfiguration, is it possible to get
> DefaultGrailsDomainConfiguration object?
>
> Did I missed out any important step? Please advice, thanks.
>
> Code of item 1:
> ==========
>         def gcl = new GrailsAwareClassLoader()
>         def injector = new DefaultGrailsDomainClassInjector() {
>             boolean shouldInject(URL url) { true }
>             protected boolean isDomainClass(ClassNode classNode, SourceUnit
> sourceNode) { true  }
>             protected boolean shouldInjectClass(ClassNode classNode) { true
> }
>                 }
>
>         gcl.setClassInjectors([injector] as ClassInjector[])
>
>             GrailsDomainClass domainClass =
> grailsApplication.addArtefact(DomainClassArtefactHandler.TYPE,
>         gcl.parseClass("""
> package vacationRequest
>
> class VacationRequest {
>     String employeeName
>     Integer numberOfDays
>     String vacationDescription
>     String approvalRemark
>     Boolean resendRequest
>     Date dateCreated
>     Date lastUpdated
>
>   static constraints = {
>         employeeName blank:false, size:5..50
>         numberOfDays range:1..14
>         vacationDescription blank:false, size:5..255
>         approvalRemark nullable:true
>         resendRequest nullable:true
>         dateCreated blank:false
>         lastUpdated nullable:true
>     }
> }
>                 """))
>         grailsApplication.domainClasses.each {
>             println it
>         }
>
> Regards,
> Chee Kin
>

This really sounds like a suspect thing to be doing at the application
level.  Maybe there are good reasons to do this for your app in
particular but in general this would not be a good idea.

Have you sorted through what you are really trying to accomplish and
made sure that you really do want to be creating domain classes at
runtime?



jb

--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Gavin-15
Chee Kin Lim wrote:
Hi Jeff,

Thanks for writing.

The requirement of dynamic domain class creation is related to creation of the Grails Form Builder plugin. Let's say user can create the form using browser-based Form Builder, how should the plugin stored data for form defined by user (I means form data like invoice, order, news, etc., not the form meta-data like label, field, field type, etc)? There is two ways in my opinion:
1) Create a generic domain class to store data of all forms
2) Each form have it own domain class(es) to store it's own data. (My preferred option, but seems like not practical as it needs dynamic domain class)

What do you think? You can find out more background information of the
Grails Form Builder plugin at http://grails.1312388.n4.nabble.com/Grails-Form-Builder-Plugin-td2818208.html

You input and feedback is very much appreciated. Thanks.

Regards,
Chee Kin
Hi,

If dynamic domain classes proves to be a very hard road then something else to consider is db4o.
Object oriented database, you won't get GORM features and I'm only in the early stages of assessing it
but basic persistence seems to be a synch with no mapping and it is mature.

I guess a db4o plugin would be required and another form builder plugin to create and load persistent classes (just normal Java/Groovy classes)
into the jvm container. There is a db40 plugin in Griffon.

Cheers
Gavin
--
www.gnumims.org
www.kromhouts.net
Everything in moderation, including moderation itself.
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
In reply to this post by Jeff Scott Brown
Hi Jeff,

For your information, the freemarker plugin is not working even with the workaround, please see my comment for jira issue at http://jira.codehaus.org/browse/GRAILS-6221.

Please advice.

Regards,
Chee Kin

On Mon, Oct 11, 2010 at 11:13 PM, Jeff Brown-3 [via Grails] <[hidden email]> wrote:
On Mon, Oct 11, 2010 at 4:59 AM, Chee Kin Lim <[hidden email]> wrote:

> Hi there,
>
> I love GORM a lot and would like to give it a try. Below is some of my
> findings for Dynamic Domain Class creation:
> 1. Create a domain class from String text, but I not sure using
> GrailsAwareClassLoader to parseClass is the correct way (The code is at the
> end of the message, please advice)
> 2. Instantiate the domain class bean to Spring ApplicationContext and
> enhance it like the way show in DomainClassGrailsPlugin.groovy's
> doWithDynamicMethods.
> 3. Instantiate HibernateDomainClassValidator for the domain class bean and
> enhance it like the way show in HibernatePluginSupport.groovy's
> doWithDynamicMethods
> 4. How do Hibernate know the new domain class instantiated and create the
> corresponding schema, by DefaultGrailsDomainConfiguration.addDomainClass? By
> reading the API doc, I couldn't find any way to access to
> DefaultGrailsDomainConfiguration, is it possible to get
> DefaultGrailsDomainConfiguration object?
>
> Did I missed out any important step? Please advice, thanks.
>
> Code of item 1:
> ==========
>         def gcl = new GrailsAwareClassLoader()
>         def injector = new DefaultGrailsDomainClassInjector() {
>             boolean shouldInject(URL url) { true }
>             protected boolean isDomainClass(ClassNode classNode, SourceUnit
> sourceNode) { true  }
>             protected boolean shouldInjectClass(ClassNode classNode) { true
> }
>                 }
>
>         gcl.setClassInjectors([injector] as ClassInjector[])
>
>             GrailsDomainClass domainClass =
> grailsApplication.addArtefact(DomainClassArtefactHandler.TYPE,
>         gcl.parseClass("""
> package vacationRequest
>
> class VacationRequest {
>     String employeeName
>     Integer numberOfDays
>     String vacationDescription
>     String approvalRemark
>     Boolean resendRequest
>     Date dateCreated
>     Date lastUpdated
>
>   static constraints = {
>         employeeName blank:false, size:5..50
>         numberOfDays range:1..14
>         vacationDescription blank:false, size:5..255
>         approvalRemark nullable:true
>         resendRequest nullable:true
>         dateCreated blank:false
>         lastUpdated nullable:true
>     }
> }
>                 """))
>         grailsApplication.domainClasses.each {
>             println it
>         }
>
> Regards,
> Chee Kin
>
This really sounds like a suspect thing to be doing at the application
level.  Maybe there are good reasons to do this for your app in
particular but in general this would not be a good idea.

Have you sorted through what you are really trying to accomplish and
made sure that you really do want to be creating domain classes at
runtime?



jb

--
Jeff Brown
SpringSource
http://www.springsource.com/

Autism Strikes 1 in 166
Find The Cause ~ Find The Cure
http://www.autismspeaks.org/

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

    http://xircles.codehaus.org/manage_email





View message @ http://grails.1312388.n4.nabble.com/Dynamic-Compilation-tp2964601p2989968.html
To unsubscribe from Dynamic Compilation, click here.


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Jorge Uriarte Aretxaga
In reply to this post by Lim Chee Kin
The requirement of dynamic domain class creation is related to creation of the Grails Form Builder plugin. Let's say user can create the form using browser-based Form Builder, how should the plugin stored data for form defined by user (I means form data like invoice, order, news, etc., not the form meta-data like label, field, field type, etc)? There is two ways in my opinion:
1) Create a generic domain class to store data of all forms
2) Each form have it own domain class(es) to store it's own data. (My preferred option, but seems like not practical as it needs dynamic domain class)


I'd go for the 1) approach based on some arguments:

Practical argument: What's the model provided to programatically access stored data from other services, applications, etc...?
If the domain classes are generated "on the fly" based on other data (form definition), coding against them would be somehow coding on an "API-to-be", no compile-time checking, no code to explore...
Accessing the data from a unified form-data domain class would follow the law of less surprise, and would be a better approach IMHO. You can provide "binders" so any given domain class (outside your plugin) can be instantiated from/to your store, as an integration model.

Theoretical argument: A class is, by definition, data+behaviour. Your so-called "domain classes" would be just data, so no need for full-blown "domain class" artifacts arises, again IMHO. I know, I know; hibernate and gorm makes soooo easy to model database entities that we no longer reflect on the fact of the domain class being or not needed. But I still think that we *must* take the time to reflect on our application design. If the data we will store is per-se an entity of the system, it will probably have some associated behaviour your generic "on-the-fly" classes will hardly provide. If it's not... we probably got enough with a generic store system.

Smell argument: The application domain of your plugin is quite generic and simple, but somehow your implementation roadmap seems too complex. Smells like overengineering to me. Don't get me wrong; I *love* that smell. Is just that it usually doesn't pay ;)

My too cents ;)

_
Jorge Uriarte
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Scott Davis-7
In reply to this post by Lim Chee Kin
Chee Kin,

I think that you are barking up the wrong tree WRT GORM. It is for mapping fixed classes to fixed database tables -- both defined before the app boots up. It sounds like you are trying to optimize on flexibility -- perhaps a NoSQL (schema-less key/value pair datastore) is closer to what you are looking for.

I'd look at Groovy Expandos <http://groovy.codehaus.org/Collections> -- they are essentially hashmap-like objects that can be defined on the fly. Then I'd look at CouchDB -- it uses JSON for its data format and REST for its interface. This combination will give you the flexibility you are looking for to dynamically define new domain classes on the fly at run-time.

HTH,
s

Scott Davis
[hidden email]

ThirstyHead: training done right
http://thirstyhead.com

On Oct 11, 2010, at 8:22 PM, Chee Kin Lim wrote:

> Hi Jeff,
>
> Thanks for writing.
>
> The requirement of dynamic domain class creation is related to creation of the Grails Form Builder plugin. Let's say user can create the form using browser-based Form Builder, how should the plugin stored data for form defined by user (I means form data like invoice, order, news, etc., not the form meta-data like label, field, field type, etc)? There is two ways in my opinion:
> 1) Create a generic domain class to store data of all forms
> 2) Each form have it own domain class(es) to store it's own data. (My preferred option, but seems like not practical as it needs dynamic domain class)
>
> What do you think? You can find out more background information of the Grails Form Builder plugin at http://grails.1312388.n4.nabble.com/Grails-Form-Builder-Plugin-td2818208.html
>
> You input and feedback is very much appreciated. Thanks.
>
> Regards,
> Chee Kin
>
>
> On Mon, Oct 11, 2010 at 11:13 PM, Jeff Brown <[hidden email]> wrote:
> On Mon, Oct 11, 2010 at 4:59 AM, Chee Kin Lim <[hidden email]> wrote:
> > Hi there,
> >
> > I love GORM a lot and would like to give it a try. Below is some of my
> > findings for Dynamic Domain Class creation:
> > 1. Create a domain class from String text, but I not sure using
> > GrailsAwareClassLoader to parseClass is the correct way (The code is at the
> > end of the message, please advice)
> > 2. Instantiate the domain class bean to Spring ApplicationContext and
> > enhance it like the way show in DomainClassGrailsPlugin.groovy's
> > doWithDynamicMethods.
> > 3. Instantiate HibernateDomainClassValidator for the domain class bean and
> > enhance it like the way show in HibernatePluginSupport.groovy's
> > doWithDynamicMethods
> > 4. How do Hibernate know the new domain class instantiated and create the
> > corresponding schema, by DefaultGrailsDomainConfiguration.addDomainClass? By
> > reading the API doc, I couldn't find any way to access to
> > DefaultGrailsDomainConfiguration, is it possible to get
> > DefaultGrailsDomainConfiguration object?
> >
> > Did I missed out any important step? Please advice, thanks.
> >
> > Code of item 1:
> > ==========
> >         def gcl = new GrailsAwareClassLoader()
> >         def injector = new DefaultGrailsDomainClassInjector() {
> >             boolean shouldInject(URL url) { true }
> >             protected boolean isDomainClass(ClassNode classNode, SourceUnit
> > sourceNode) { true  }
> >             protected boolean shouldInjectClass(ClassNode classNode) { true
> > }
> >                 }
> >
> >         gcl.setClassInjectors([injector] as ClassInjector[])
> >
> >             GrailsDomainClass domainClass =
> > grailsApplication.addArtefact(DomainClassArtefactHandler.TYPE,
> >         gcl.parseClass("""
> > package vacationRequest
> >
> > class VacationRequest {
> >     String employeeName
> >     Integer numberOfDays
> >     String vacationDescription
> >     String approvalRemark
> >     Boolean resendRequest
> >     Date dateCreated
> >     Date lastUpdated
> >
> >   static constraints = {
> >         employeeName blank:false, size:5..50
> >         numberOfDays range:1..14
> >         vacationDescription blank:false, size:5..255
> >         approvalRemark nullable:true
> >         resendRequest nullable:true
> >         dateCreated blank:false
> >         lastUpdated nullable:true
> >     }
> > }
> >                 """))
> >         grailsApplication.domainClasses.each {
> >             println it
> >         }
> >
> > Regards,
> > Chee Kin
> >
>
> This really sounds like a suspect thing to be doing at the application
> level.  Maybe there are good reasons to do this for your app in
> particular but in general this would not be a good idea.
>
> Have you sorted through what you are really trying to accomplish and
> made sure that you really do want to be creating domain classes at
> runtime?
>
>
>
> jb
>
> --
> Jeff Brown
> SpringSource
> http://www.springsource.com/
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>




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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
In reply to this post by Gavin-15
Hi Gavin,

Thanks for writing.

db4o maybe another viable option to evaluate. Thanks for inform me about it.

For your information, I am working on Dynamic Domain Class plugin that stay comply to standard Grails stack as much as possible such as Domain Class + Validation + GORM + Hibernate + RDBMS. If you are interested in Dynamic Domain Class plugin project, I am welcome you to have a look at http://code.google.com/p/grails-dynamic-domain-class-plugin/

Let's see how the project turn out...

Regards,
Chee Kin


If dynamic domain classes proves to be a very hard road then something else to consider is db4o.
Object oriented database, you won't get GORM features and I'm only in the early stages of assessing it
but basic persistence seems to be a synch with no mapping and it is mature.

I guess a db4o plugin would be required and another form builder plugin to create and load persistent classes (just normal Java/Groovy classes)
into the jvm container. There is a db40 plugin in Griffon.

Cheers
Gavin
--
www.gnumims.org
www.kromhouts.net
Everything in moderation, including moderation itself.

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
In reply to this post by Jorge Uriarte Aretxaga
Hi Jorge,

Thanks for writing.

For the unified form-data domain class, you mentioned about "binders" to any given domain class. I not so sure I am understood the meaning of "binders", is it like how the Grails controller bind the params to domain class?

Regards,
Chee Kin


On Tue, Oct 12, 2010 at 5:09 PM, Jorge Uriarte Aretxaga <[hidden email]> wrote:
The requirement of dynamic domain class creation is related to creation of the Grails Form Builder plugin. Let's say user can create the form using browser-based Form Builder, how should the plugin stored data for form defined by user (I means form data like invoice, order, news, etc., not the form meta-data like label, field, field type, etc)? There is two ways in my opinion:
1) Create a generic domain class to store data of all forms
2) Each form have it own domain class(es) to store it's own data. (My preferred option, but seems like not practical as it needs dynamic domain class)


I'd go for the 1) approach based on some arguments:

Practical argument: What's the model provided to programatically access stored data from other services, applications, etc...?
If the domain classes are generated "on the fly" based on other data (form definition), coding against them would be somehow coding on an "API-to-be", no compile-time checking, no code to explore...
Accessing the data from a unified form-data domain class would follow the law of less surprise, and would be a better approach IMHO. You can provide "binders" so any given domain class (outside your plugin) can be instantiated from/to your store, as an integration model.

Theoretical argument: A class is, by definition, data+behaviour. Your so-called "domain classes" would be just data, so no need for full-blown "domain class" artifacts arises, again IMHO. I know, I know; hibernate and gorm makes soooo easy to model database entities that we no longer reflect on the fact of the domain class being or not needed. But I still think that we *must* take the time to reflect on our application design. If the data we will store is per-se an entity of the system, it will probably have some associated behaviour your generic "on-the-fly" classes will hardly provide. If it's not... we probably got enough with a generic store system.

Smell argument: The application domain of your plugin is quite generic and simple, but somehow your implementation roadmap seems too complex. Smells like overengineering to me. Don't get me wrong; I *love* that smell. Is just that it usually doesn't pay ;)

My too cents ;)

_
Jorge Uriarte

Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
In reply to this post by Scott Davis-7
Hi Scott,

Yeah! The NoSQL option did pop-up from my mind. If I am unable to make it works with RDBMS (which I am familiar), I will definitely look into NoSQL. I will keep CouchDB in mind.

Thanks for advice.

Regards,
Chee Kin



On Tue, Oct 12, 2010 at 10:58 PM, Scott Davis <[hidden email]> wrote:
Chee Kin,

I think that you are barking up the wrong tree WRT GORM. It is for mapping fixed classes to fixed database tables -- both defined before the app boots up. It sounds like you are trying to optimize on flexibility -- perhaps a NoSQL (schema-less key/value pair datastore) is closer to what you are looking for.

I'd look at Groovy Expandos <http://groovy.codehaus.org/Collections> -- they are essentially hashmap-like objects that can be defined on the fly. Then I'd look at CouchDB -- it uses JSON for its data format and REST for its interface. This combination will give you the flexibility you are looking for to dynamically define new domain classes on the fly at run-time.

HTH,
s

Scott Davis
[hidden email]

ThirstyHead: training done right
http://thirstyhead.com

On Oct 11, 2010, at 8:22 PM, Chee Kin Lim wrote:

> Hi Jeff,
>
> Thanks for writing.
>
> The requirement of dynamic domain class creation is related to creation of the Grails Form Builder plugin. Let's say user can create the form using browser-based Form Builder, how should the plugin stored data for form defined by user (I means form data like invoice, order, news, etc., not the form meta-data like label, field, field type, etc)? There is two ways in my opinion:
> 1) Create a generic domain class to store data of all forms
> 2) Each form have it own domain class(es) to store it's own data. (My preferred option, but seems like not practical as it needs dynamic domain class)
>
> What do you think? You can find out more background information of the Grails Form Builder plugin at http://grails.1312388.n4.nabble.com/Grails-Form-Builder-Plugin-td2818208.html
>
> You input and feedback is very much appreciated. Thanks.
>
> Regards,
> Chee Kin
>
>
> On Mon, Oct 11, 2010 at 11:13 PM, Jeff Brown <[hidden email]> wrote:
> On Mon, Oct 11, 2010 at 4:59 AM, Chee Kin Lim <[hidden email]> wrote:
> > Hi there,
> >
> > I love GORM a lot and would like to give it a try. Below is some of my
> > findings for Dynamic Domain Class creation:
> > 1. Create a domain class from String text, but I not sure using
> > GrailsAwareClassLoader to parseClass is the correct way (The code is at the
> > end of the message, please advice)
> > 2. Instantiate the domain class bean to Spring ApplicationContext and
> > enhance it like the way show in DomainClassGrailsPlugin.groovy's
> > doWithDynamicMethods.
> > 3. Instantiate HibernateDomainClassValidator for the domain class bean and
> > enhance it like the way show in HibernatePluginSupport.groovy's
> > doWithDynamicMethods
> > 4. How do Hibernate know the new domain class instantiated and create the
> > corresponding schema, by DefaultGrailsDomainConfiguration.addDomainClass? By
> > reading the API doc, I couldn't find any way to access to
> > DefaultGrailsDomainConfiguration, is it possible to get
> > DefaultGrailsDomainConfiguration object?
> >
> > Did I missed out any important step? Please advice, thanks.
> >
> > Code of item 1:
> > ==========
> >         def gcl = new GrailsAwareClassLoader()
> >         def injector = new DefaultGrailsDomainClassInjector() {
> >             boolean shouldInject(URL url) { true }
> >             protected boolean isDomainClass(ClassNode classNode, SourceUnit
> > sourceNode) { true  }
> >             protected boolean shouldInjectClass(ClassNode classNode) { true
> > }
> >                 }
> >
> >         gcl.setClassInjectors([injector] as ClassInjector[])
> >
> >             GrailsDomainClass domainClass =
> > grailsApplication.addArtefact(DomainClassArtefactHandler.TYPE,
> >         gcl.parseClass("""
> > package vacationRequest
> >
> > class VacationRequest {
> >     String employeeName
> >     Integer numberOfDays
> >     String vacationDescription
> >     String approvalRemark
> >     Boolean resendRequest
> >     Date dateCreated
> >     Date lastUpdated
> >
> >   static constraints = {
> >         employeeName blank:false, size:5..50
> >         numberOfDays range:1..14
> >         vacationDescription blank:false, size:5..255
> >         approvalRemark nullable:true
> >         resendRequest nullable:true
> >         dateCreated blank:false
> >         lastUpdated nullable:true
> >     }
> > }
> >                 """))
> >         grailsApplication.domainClasses.each {
> >             println it
> >         }
> >
> > Regards,
> > Chee Kin
> >
>
> This really sounds like a suspect thing to be doing at the application
> level.  Maybe there are good reasons to do this for your app in
> particular but in general this would not be a good idea.
>
> Have you sorted through what you are really trying to accomplish and
> made sure that you really do want to be creating domain classes at
> runtime?
>
>
>
> jb
>
> --
> Jeff Brown
> SpringSource
> http://www.springsource.com/
>
> Autism Strikes 1 in 166
> Find The Cause ~ Find The Cure
> http://www.autismspeaks.org/
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>




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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
In reply to this post by Lim Chee Kin
Hi,

Thanks for input from all of you.

FYI, I had documented my design idea for the Grails Form Builder plugin at https://docs.google.com/document/edit?id=1RcSV2xVm4MXA85GUk7_7x8W_GpA9-g3J9AJUDAgKCUE&hl=en&authkey=CJbw0MUM

Your feedback is very important to us and very much appreciated.
Please tell us what is in your mind!

Thanks.

Regards,
Chee Kin
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Jorge Uriarte Aretxaga
In reply to this post by Lim Chee Kin

exactly, a way for easily moldong info from the store to domain classes ander back.

El 13/10/2010 06:02, "Chee Kin Lim" <[hidden email]> escribió:
> Hi Jorge,
>
> Thanks for writing.
>
> For the unified form-data domain class, you mentioned about "binders" to any
> given domain class. I not so sure I am understood the meaning of "binders",
> is it like how the Grails controller bind the params to domain class?
>
> Regards,
> Chee Kin
>
>
> On Tue, Oct 12, 2010 at 5:09 PM, Jorge Uriarte Aretxaga <
> [hidden email]> wrote:
>
>> The requirement of dynamic domain class creation is related to creation of
>>> the Grails Form Builder plugin. Let's say user can create the form using
>>> browser-based Form Builder, how should the plugin stored data for form
>>> defined by user (I means form data like invoice, order, news, etc., not the
>>> form meta-data like label, field, field type, etc)? There is two ways in my
>>> opinion:
>>> 1) Create a generic domain class to store data of all forms
>>> 2) Each form have it own domain class(es) to store it's own data. (My
>>> preferred option, but seems like not practical as it needs dynamic domain
>>> class)
>>>
>>>
>> I'd go for the 1) approach based on some arguments:
>>
>> Practical argument: What's the model provided to programatically access
>> stored data from other services, applications, etc...?
>> If the domain classes are generated "on the fly" based on other data (form
>> definition), coding against them would be somehow coding on an "API-to-be",
>> no compile-time checking, no code to explore...
>> Accessing the data from a unified form-data domain class would follow the
>> law of less surprise, and would be a better approach IMHO. You can provide
>> "binders" so any given domain class (outside your plugin) can be
>> instantiated from/to your store, as an integration model.
>>
>> Theoretical argument: A class is, by definition, data+behaviour. Your
>> so-called "domain classes" would be just data, so no need for full-blown
>> "domain class" artifacts arises, again IMHO. I know, I know; hibernate and
>> gorm makes soooo easy to model database entities that we no longer reflect
>> on the fact of the domain class being or not needed. But I still think that
>> we *must* take the time to reflect on our application design. If the data we
>> will store is per-se an entity of the system, it will probably have some
>> associated behaviour your generic "on-the-fly" classes will hardly provide.
>> If it's not... we probably got enough with a generic store system.
>>
>> Smell argument: The application domain of your plugin is quite generic and
>> simple, but somehow your implementation roadmap seems too complex. Smells
>> like overengineering to me. Don't get me wrong; I *love* that smell. Is just
>> that it usually doesn't pay ;)
>>
>> My too cents ;)
>>
>> _
>> Jorge Uriarte
>> http://www.linkedin.com/in/jorgeuriarte
>> www.gailen.es
>>
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic Compilation

Lim Chee Kin
Hi there,

I would like to announce the Grails Dynamic Domain Class Plugin 0.2 Released. Please see the announcement news at http://www.grails.org/blog/view/limcheekin/Grails+Dynamic+Domain+Class+Plugin+0.2+Released+-+Create+domain+class+on-the-fly

Regards,
Chee Kin