[grails-dev] RoR implicit model classes

[graemer]

Should we support the RoR mechanism of defining the model where the
properties of the model are actually created at runtime from the
database schema?

so you can define a domain class as:

class User {

}


and thats it.. no more code needed the properties are then injected
into it as dynamic properties from the db schema

What do you think?

Graeme

[Dierk König]

I don't think that has to go into the runtime core.
We could follow the hibernate approach and provide an extra tool
that generates models from the db.
But that's only my admittedly biased opinion since I always like
to create the db schema on my own...

cheers
Mittie

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]On Behalf
> Of Graeme Rocher
> Sent: Samstag, 29. Oktober 2005 12:09
> To: [hidden email]
> Subject: [grails-dev] RoR implicit model classes
>
>
> Should we support the RoR mechanism of defining the model where the
> properties of the model are actually created at runtime from the
> database schema?
>
> so you can define a domain class as:
>
> class User {
>
> }
>
>
> and thats it.. no more code needed the properties are then injected
> into it as dynamic properties from the db schema
>
> What do you think?
>
> Graeme

[graemer]

Ok but one concern i have which is linked into scaffolding is that RoR
uses the database constraints to define what type of component to use
the render the view.. for example if it is a varchar column with a max
length of 16 a text input field is appropriate but if it is a text
column in the database that stores any amount of text a text area is
more appropriate

But maybe we can link this into the validation mechanism in rails so instead of

@Property validate = {
       loginMaxLength(16)
}

We can have

@Property constraints = {
      loginMaxLength(16)
}

Which is then also used to render the scaffolding view for the model.
I do think that doing what RoR does is very feasable though.. we could
use DDLUtils (http://db.apache.org/ddlutils/api-usage.html) to achieve
this

Graeme


On 29/10/05, Dierk Koenig <[hidden email]> wrote:

> I don't think that has to go into the runtime core.
> We could follow the hibernate approach and provide an extra tool
> that generates models from the db.
> But that's only my admittedly biased opinion since I always like
> to create the db schema on my own...
>
> cheers
> Mittie
>
>
> > -----Original Message-----
> > From: [hidden email] [mailto:[hidden email]]On Behalf
> > Of Graeme Rocher
> > Sent: Samstag, 29. Oktober 2005 12:09
> > To: [hidden email]
> > Subject: [grails-dev] RoR implicit model classes
> >
> >
> > Should we support the RoR mechanism of defining the model where the
> > properties of the model are actually created at runtime from the
> > database schema?
> >
> > so you can define a domain class as:
> >
> > class User {
> >
> > }
> >
> >
> > and thats it.. no more code needed the properties are then injected
> > into it as dynamic properties from the db schema
> >
> > What do you think?
> >
> > Graeme
>

[Dierk König]

> We can have
>
> @Property constraints = {
>       loginMaxLength(16)
> }
just a thought:
        loginMaxLength = 16
or
        login.maxLength = 16
would also read nicely :-)

It seems we kind of need this info anyway since
when creating the schema from a domain class,
what length should we assume for properties of
type String?

BTW: a view and a controller may have stronger
validation constraints than the model.

cheers
Mittie

[graemer]

On 29/10/05, Dierk Koenig <[hidden email]> wrote:
> > We can have
> >
> > @Property constraints = {
> >       loginMaxLength(16)
> > }
> just a thought:
>         loginMaxLength = 16
> or
>         login.maxLength = 16

Great idea! We could have properties of the domain class dynamic so
that they have information attached about the constraints

@Property constraints = {
         this.login.maxLength = 17
         this.login.unique = true
}

> would also read nicely :-)
>
> It seems we kind of need this info anyway since
> when creating the schema from a domain class,
> what length should we assume for properties of
> type String?
>
> BTW: a view and a controller may have stronger
> validation constraints than the model.
>
> cheers
> Mittie
>

[graemer]

On 29/10/05, Graeme Rocher <[hidden email]> wrote:

> On 29/10/05, Dierk Koenig <[hidden email]> wrote:
> > > We can have
> > >
> > > @Property constraints = {
> > >       loginMaxLength(16)
> > > }
> > just a thought:
> >         loginMaxLength = 16
> > or
> >         login.maxLength = 16

hmm having thought about this i'm not sure its possible as the login
would be string which would mean we would need a custom meta class for
primites and all commonly used objects..

What do you think is there another way to do this? Unless of course
the constraints closure can somehow delegate "this" to some other
object that stores this info

Graeme

>
> Great idea! We could have properties of the domain class dynamic so
> that they have information attached about the constraints
>
> @Property constraints = {
>          this.login.maxLength = 17
>          this.login.unique = true
> }
>
> > would also read nicely :-)
> >
> > It seems we kind of need this info anyway since
> > when creating the schema from a domain class,
> > what length should we assume for properties of
> > type String?
> >
> > BTW: a view and a controller may have stronger
> > validation constraints than the model.
> >
> > cheers
> > Mittie
> >
>

[Steven Devijver-2]

On 30 Oct 2005, at 08:47, Graeme Rocher wrote:

> On 29/10/05, Graeme Rocher <[hidden email]> wrote:
>
>> On 29/10/05, Dierk Koenig <[hidden email]> wrote:
>>
>>>> We can have
>>>>
>>>> @Property constraints = {
>>>>       loginMaxLength(16)
>>>> }
>>>>
>>> just a thought:
>>>         loginMaxLength = 16
>>> or
>>>         login.maxLength = 16
>>>
>
> hmm having thought about this i'm not sure its possible as the login
> would be string which would mean we would need a custom meta class for
> primites and all commonly used objects..
>
> What do you think is there another way to do this? Unless of course
> the constraints closure can somehow delegate "this" to some other
> object that stores this info
>
> Graeme
>

Field constraints are readable from the database. Ofcourse, if we go  
down
that road we wave testing in isolation goodbye.

Steven

>
>>
>> Great idea! We could have properties of the domain class dynamic so
>> that they have information attached about the constraints
>>
>> @Property constraints = {
>>          this.login.maxLength = 17
>>          this.login.unique = true
>> }
>>
>>
>>> would also read nicely :-)
>>>
>>> It seems we kind of need this info anyway since
>>> when creating the schema from a domain class,
>>> what length should we assume for properties of
>>> type String?
>>>
>>> BTW: a view and a controller may have stronger
>>> validation constraints than the model.
>>>
>>> cheers
>>> Mittie
>>>
>>>
>>
>

[Dierk König]

> > > just a thought:
> > >         loginMaxLength = 16
> > > or
> > >         login.maxLength = 16
>
> hmm having thought about this i'm not sure its possible as the login
> would be string which would mean we would need a custom meta class for
> primites and all commonly used objects..
>
> What do you think is there another way to do this? Unless of course
> the constraints closure can somehow delegate "this" to some other
> object that stores this info

 loginMaxLength = 16
is equivalent to
 setLoginMaxLength(16)
so this can be handled by a builder or equivalent.

 login.maxLength = 16
could be done with a ProxyMetaClass/Interceptor that intercepts all
method calls of well-known names (e.g.setMaxLength).
But I'm not sure it's worth the effort.

cheers
Mittie

[graemer]

On 30/10/05, Dierk Koenig <[hidden email]> wrote:

> > > > just a thought:
> > > >         loginMaxLength = 16
> > > > or
> > > >         login.maxLength = 16
> >
> > hmm having thought about this i'm not sure its possible as the login
> > would be string which would mean we would need a custom meta class for
> > primites and all commonly used objects..
> >
> > What do you think is there another way to do this? Unless of course
> > the constraints closure can somehow delegate "this" to some other
> > object that stores this info
>
>  loginMaxLength = 16
> is equivalent to
>  setLoginMaxLength(16)
> so this can be handled by a builder or equivalent.
>
>  login.maxLength = 16
> could be done with a ProxyMetaClass/Interceptor that intercepts all
> method calls of well-known names (e.g.setMaxLength).
> But I'm not sure it's worth the effort.

It maybe be worth the effort as i prefer the syntax but my concern is
that a String is not a GroovyObject it gets its MetaClass from the
registry if i'm not mistaken.. so that means  what we would need to do
is register a custom meta class for String (and all the other common
types) in the registry especifically for Grails.

Either that or change the meta class on the domain object to return a
wrapper class like "ConstrainedString".. that had a
ProxyMetaClass/Interceptor

but as I said if you have another idea how we could implement this let
me know as I do prefer the syntax:

this.login.maxLength = 10

As it seems more like you're setting it against the property.

Steven, I think we should go down this route as testing in isolation
is important and there are also other custom contrainst we could apply
to domain class properties that can't be tied to a database (see RIFE
constraints for examples of these)

>
> cheers
> Mittie
>

[Dierk König]

> >  login.maxLength = 16
> > could be done with a ProxyMetaClass/Interceptor that intercepts all
> > method calls of well-known names (e.g.setMaxLength).
> > But I'm not sure it's worth the effort.
>
> It maybe be worth the effort as i prefer the syntax but my concern is
> that a String is not a GroovyObject it gets its MetaClass from the
> registry if i'm not mistaken..

ProxyMetaClass currently intercepts only method calls to a
well-known class (this can also be java.lang.String).
But that could be easily extended for our purposes
to a list of classes, a class-name pattern, or all classes.
It would actually work even with the existing ProxyMetaClass but
would require constructing a new one around each method call :-(

> but as I said if you have another idea how we could implement this let
> me know as I do prefer the syntax:
>
> this.login.maxLength = 10
>
> As it seems more like you're setting it against the property.

Yes, cool and much easier. +1

Mittie

[graemer]

ok having thought about this some more i think i know how we can do
it..basically we have a closure property called "constraints"

@Property constraints = {}

we intercept a call to either getProperty("constraints") and get it to
execute the closure rather than returning it

before executing the closure we temporarily change the metaclass of
the domain object for the scope of the closure call (we set it back to
the original in the after() call of the interceptor)

We use a proxy metaclass to intercept all calls to properties on the
domain class and wrap them in a ConstrainProperty class before
returning them (they will be created on the first call to "this.login"
for example)

At the end of the closure a list of ConstrainProperty instances will
have been built up and returned by the closure (after setting the
metaclass back to the original)

The "validate()" closure then uses these and you can also loop over
them for example:

@Property validate = {
this.constraints.each {
    println    it.property
    println    it.minLength
   // etc
}
}


Graeme

On 30/10/05, Dierk Koenig <[hidden email]> wrote:

> > >  login.maxLength = 16
> > > could be done with a ProxyMetaClass/Interceptor that intercepts all
> > > method calls of well-known names (e.g.setMaxLength).
> > > But I'm not sure it's worth the effort.
> >
> > It maybe be worth the effort as i prefer the syntax but my concern is
> > that a String is not a GroovyObject it gets its MetaClass from the
> > registry if i'm not mistaken..
>
> ProxyMetaClass currently intercepts only method calls to a
> well-known class (this can also be java.lang.String).
> But that could be easily extended for our purposes
> to a list of classes, a class-name pattern, or all classes.
> It would actually work even with the existing ProxyMetaClass but
> would require constructing a new one around each method call :-(
>
> > but as I said if you have another idea how we could implement this let
> > me know as I do prefer the syntax:
> >
> > this.login.maxLength = 10
> >
> > As it seems more like you're setting it against the property.
>
> Yes, cool and much easier. +1
>
> Mittie
>
>
>

[Dierk König]

this is gonna be a master piece of Groovyism :-)

> before executing the closure we temporarily change the metaclass of
> the domain object for the scope of the closure call (we set it back to
> the original in the after() call of the interceptor)

Yep. We need to set it back even in case of Exceptions (try-finally).

> @Property validate = {
> this.constraints.each {
>     println    it.property
>     println    it.minLength
>    // etc
> }
> }

very nice :-)

cheers
Mittie