Grails and @Annotations

[Marcel Overdijk]

In Grails's early days Groovy did not supported @Annotations yet, so using them was not an option.
Another reason was to support Java 1.4.

These days annotations are very common and all kind of frameworks use them all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.

I'm wondering what Grails's idea's are for this in the future.

Take an example

class CountryService {
    static transactional = true
}

Could also be:

@Transactional
class CountryService {
}

But also using the JSR 303 Bean Validation annotations could be used to define constraints for domain classes.


I'm wondering if we you would create Grails today, would you choose the path of using annotations?

[burtbeckwith]

@Transactional was implemented recently and will be in 1.2: http://jira.codehaus.org/browse/GRAILS-3343

Burt

On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:

>
> In Grails's early days Groovy did not supported @Annotations yet, so using
> them was not an option.
> Another reason was to support Java 1.4.
>
> These days annotations are very common and all kind of frameworks use them
> all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.
>
> I'm wondering what Grails's idea's are for this in the future.
>
> Take an example
>
> class CountryService {
>     static transactional = true
> }
>
> Could also be:
>
> @Transactional
> class CountryService {
> }
>
> But also using the JSR 303 Bean Validation annotations could be used to
> define constraints for domain classes.
>
>
> I'm wondering if we you would create Grails today, would you choose the path
> of using annotations?

[Marcel Overdijk]

Cool! But this raises my question even further.

I wouldn't like the situation to mix @Annotations, static fields and closures to accomplish my things. I would prefer 1 approach.

Burt Beckwith wrote

@Transactional was implemented recently and will be in 1.2: http://jira.codehaus.org/browse/GRAILS-3343

Burt

On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:
>
> In Grails's early days Groovy did not supported @Annotations yet, so using
> them was not an option.
> Another reason was to support Java 1.4.
>
> These days annotations are very common and all kind of frameworks use them
> all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.
>
> I'm wondering what Grails's idea's are for this in the future.
>
> Take an example
>
> class CountryService {
>     static transactional = true
> }
>
> Could also be:
>
> @Transactional
> class CountryService {
> }
>
> But also using the JSR 303 Bean Validation annotations could be used to
> define constraints for domain classes.
>
>
> I'm wondering if we you would create Grails today, would you choose the path
> of using annotations?

 

[Robert Fischer]

+1: I'd like to keep annotations to a minimum in Grails, preferably even just leaving them to the
parent language.  Graeme's cynicism about them is well-founded.

~~ Robert.

Marcel Overdijk wrote:

> Cool! But this raises my question even further.
>
> I wouldn't like the situation to mix @Annotations, static fields and
> closures to accomplish my things. I would prefer 1 approach.
>
>
>
> Burt Beckwith wrote:
>> @Transactional was implemented recently and will be in 1.2:
>> http://jira.codehaus.org/browse/GRAILS-3343
>>
>> Burt
>>
>> On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:
>>> In Grails's early days Groovy did not supported @Annotations yet, so
>>> using
>>> them was not an option.
>>> Another reason was to support Java 1.4.
>>>
>>> These days annotations are very common and all kind of frameworks use
>>> them
>>> all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.
>>>
>>> I'm wondering what Grails's idea's are for this in the future.
>>>
>>> Take an example
>>>
>>> class CountryService {
>>>     static transactional = true
>>> }
>>>
>>> Could also be:
>>>
>>> @Transactional
>>> class CountryService {
>>> }
>>>
>>> But also using the JSR 303 Bean Validation annotations could be used to
>>> define constraints for domain classes.
>>>
>>>
>>> I'm wondering if we you would create Grails today, would you choose the
>>> path
>>> of using annotations?
>>  
>>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email

[Marcel Overdijk]

Personally I would prefer:

@Transactional

instead of:

static transactional = true


But I would only prefer them if I don't have to mix them.

Robert Fischer wrote

+1: I'd like to keep annotations to a minimum in Grails, preferably even just leaving them to the
parent language.  Graeme's cynicism about them is well-founded.

~~ Robert.

Marcel Overdijk wrote:
> Cool! But this raises my question even further.
>
> I wouldn't like the situation to mix @Annotations, static fields and
> closures to accomplish my things. I would prefer 1 approach.
>
>
>
> Burt Beckwith wrote:
>> @Transactional was implemented recently and will be in 1.2:
>> http://jira.codehaus.org/browse/GRAILS-3343
>>
>> Burt
>>
>> On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:
>>> In Grails's early days Groovy did not supported @Annotations yet, so
>>> using
>>> them was not an option.
>>> Another reason was to support Java 1.4.
>>>
>>> These days annotations are very common and all kind of frameworks use
>>> them
>>> all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.
>>>
>>> I'm wondering what Grails's idea's are for this in the future.
>>>
>>> Take an example
>>>
>>> class CountryService {
>>>     static transactional = true
>>> }
>>>
>>> Could also be:
>>>
>>> @Transactional
>>> class CountryService {
>>> }
>>>
>>> But also using the JSR 303 Bean Validation annotations could be used to
>>> define constraints for domain classes.
>>>
>>>
>>> I'm wondering if we you would create Grails today, would you choose the
>>> path
>>> of using annotations?
>>  
>>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

I've always found piles of @'s preceeding my class title to be more confusing than enlightening: not
to mention very limited in extensibility without introducing @Transactional(foo={bar={baz=true}})
and similar monstrosities.

If I wanted that crap, I'd still be coding Java.

~~ Robert.

Marcel Overdijk wrote:

> Personally I would prefer:
>
> @Transactional
>
> instead of:
>
> static transactional = true
>
>
> But I would only prefer them if I don't have to mix them.
>
>
>
> Robert Fischer wrote:
>> +1: I'd like to keep annotations to a minimum in Grails, preferably even
>> just leaving them to the
>> parent language.  Graeme's cynicism about them is well-founded.
>>
>> ~~ Robert.
>>
>> Marcel Overdijk wrote:
>>> Cool! But this raises my question even further.
>>>
>>> I wouldn't like the situation to mix @Annotations, static fields and
>>> closures to accomplish my things. I would prefer 1 approach.
>>>
>>>
>>>
>>> Burt Beckwith wrote:
>>>> @Transactional was implemented recently and will be in 1.2:
>>>> http://jira.codehaus.org/browse/GRAILS-3343
>>>>
>>>> Burt
>>>>
>>>> On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:
>>>>> In Grails's early days Groovy did not supported @Annotations yet, so
>>>>> using
>>>>> them was not an option.
>>>>> Another reason was to support Java 1.4.
>>>>>
>>>>> These days annotations are very common and all kind of frameworks use
>>>>> them
>>>>> all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.
>>>>>
>>>>> I'm wondering what Grails's idea's are for this in the future.
>>>>>
>>>>> Take an example
>>>>>
>>>>> class CountryService {
>>>>>     static transactional = true
>>>>> }
>>>>>
>>>>> Could also be:
>>>>>
>>>>> @Transactional
>>>>> class CountryService {
>>>>> }
>>>>>
>>>>> But also using the JSR 303 Bean Validation annotations could be used to
>>>>> define constraints for domain classes.
>>>>>
>>>>>
>>>>> I'm wondering if we you would create Grails today, would you choose the
>>>>> path
>>>>> of using annotations?
>>>>  
>>>>
>> --
>> ~~ Robert Fischer, Smokejumper IT Consulting.
>> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>>
>> Check out my book, "Grails Persistence with GORM and GSQL"!
>> http://www.smokejumperit.com/redirect.html
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>>
>

--
~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Check out my book, "Grails Persistence with GORM and GSQL"!
http://www.smokejumperit.com/redirect.html

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

    http://xircles.codehaus.org/manage_email

[vladk]

It is quite hard to decide what should be annotation in Grails and what shouldn't be. There are so many things in there that could be turned into annotations. You know. But me prefer to leave everything as is. To avoid a mess. IMHO.

Marcel Overdijk wrote

In Grails's early days Groovy did not supported @Annotations yet, so using them was not an option.
Another reason was to support Java 1.4.

These days annotations are very common and all kind of frameworks use them all around. Spring, Hibernate, Groovy and also JSR 303 Bean Validation.

I'm wondering what Grails's idea's are for this in the future.

Take an example

class CountryService {
    static transactional = true
}

Could also be:

@Transactional
class CountryService {
}

But also using the JSR 303 Bean Validation annotations could be used to define constraints for domain classes.


I'm wondering if we you would create Grails today, would you choose the path of using annotations?

[Robert Fletcher]

This is something I was thinking about some while back. From a purist
Java approach the way Grails uses static (or even more so non-static)
properties is a bit odd - they should really be static final. What is
the behaviour or expected behaviour if I programmatically reassign
`static transactional = false` on a service, for example? Annotations
also have the advantage of compile time checking. This has bitten me
in the past when I've pluralised the mapping closure on a domain
class.

As anyone who has declared a Map collection on a Hibernate annotated
class can tell you, though, annotations can get really complex and
unreadable. Imagine how awful domain class constraints would look
expressed as annotations.

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

    http://xircles.codehaus.org/manage_email

[kaaloo]

I agree, annotations are probably only justified when in type safe
mode, like when using Guice or something in a component etc..., or
when Grails doesn't support something, it would definitely impact the
elegance and simplicity of the current syntax.

Luis

On Mon, Jul 27, 2009 at 4:11 PM, Vlad
Kasianenko<[hidden email]> wrote:
>
> It is quite hard to decide what should be annotation in Grails and what
> shouldn't be. There are so many things in there that could be turned into
> annotations. You know. But me prefer to leave everything as is. To avoid a
> mess. IMHO.
>
>


--
Luis Arias
[phone]
skype : kaaloo

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

    http://xircles.codehaus.org/manage_email

[Wilson MacGyver]

I think that as grails grow, more and more people learning it may not
be coming from Java background.

In that case, @Annotations maybe less newcomer friendly?

because everyone understands assignments.

On Mon, Jul 27, 2009 at 11:29 AM, Robert
Fletcher<[hidden email]> wrote:

> This is something I was thinking about some while back. From a purist
> Java approach the way Grails uses static (or even more so non-static)
> properties is a bit odd - they should really be static final. What is
> the behaviour or expected behaviour if I programmatically reassign
> `static transactional = false` on a service, for example? Annotations
> also have the advantage of compile time checking. This has bitten me
> in the past when I've pluralised the mapping closure on a domain
> class.
>
> As anyone who has declared a Map collection on a Hibernate annotated
> class can tell you, though, annotations can get really complex and
> unreadable. Imagine how awful domain class constraints would look
> expressed as annotations.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Omnem crede diem tibi diluxisse supremum.

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

    http://xircles.codehaus.org/manage_email

[Björn Wilmsmann-2]

I agree,

@Transactional means less typing than static transactional = true but  
then again, the latter is much more explicit. Moreover, anything but  
the standard case (like the 'beautiful' example below) quickly becomes  
so clumsy that XML configuration looks downright in comparison.

Robert Fischer wrote:

> I've always found piles of @'s preceeding my class title to be more  
> confusing than enlightening: not to mention very limited in  
> extensibility without introducing  
> @Transactional(foo={bar={baz=true}}) and similar monstrosities.
>
> If I wanted that crap, I'd still be coding Java.
>
> ~~ Robert.
>
> Marcel Overdijk wrote:
>> Personally I would prefer:
>> @Transactional instead of:
>> static transactional = true
>> But I would only prefer them if I don't have to mix them.
>> Robert Fischer wrote:
>>> +1: I'd like to keep annotations to a minimum in Grails,  
>>> preferably even
>>> just leaving them to the parent language.  Graeme's cynicism about  
>>> them is well-founded.
>>>
>>> ~~ Robert.
>>>
>>> Marcel Overdijk wrote:
>>>> Cool! But this raises my question even further.
>>>>
>>>> I wouldn't like the situation to mix @Annotations, static fields  
>>>> and
>>>> closures to accomplish my things. I would prefer 1 approach.
>>>>
>>>>
>>>>
>>>> Burt Beckwith wrote:
>>>>> @Transactional was implemented recently and will be in 1.2:
>>>>> http://jira.codehaus.org/browse/GRAILS-3343
>>>>>
>>>>> Burt
>>>>>
>>>>> On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:
>>>>>> In Grails's early days Groovy did not supported @Annotations  
>>>>>> yet, so
>>>>>> using
>>>>>> them was not an option.
>>>>>> Another reason was to support Java 1.4.
>>>>>>
>>>>>> These days annotations are very common and all kind of  
>>>>>> frameworks use
>>>>>> them
>>>>>> all around. Spring, Hibernate, Groovy and also JSR 303 Bean  
>>>>>> Validation.
>>>>>>
>>>>>> I'm wondering what Grails's idea's are for this in the future.
>>>>>>
>>>>>> Take an example
>>>>>>
>>>>>> class CountryService {
>>>>>>    static transactional = true
>>>>>> }
>>>>>>
>>>>>> Could also be:
>>>>>>
>>>>>> @Transactional
>>>>>> class CountryService {
>>>>>> }
>>>>>>
>>>>>> But also using the JSR 303 Bean Validation annotations could be  
>>>>>> used to
>>>>>> define constraints for domain classes.
>>>>>>
>>>>>>
>>>>>> I'm wondering if we you would create Grails today, would you  
>>>>>> choose the
>>>>>> path
>>>>>> of using annotations?
>>>>>
>>> --
>>> ~~ Robert Fischer, Smokejumper IT Consulting.
>>> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>>>
>>> Check out my book, "Grails Persistence with GORM and GSQL"!
>>> http://www.smokejumperit.com/redirect.html
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>>
>
> --
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Check out my book, "Grails Persistence with GORM and GSQL"!
> http://www.smokejumperit.com/redirect.html
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>

--
Viele Grüße / Best regards, Björn Wilmsmann
Geschäftsführer / CEO

----------------------
MetaSieve Dömges, Wilmsmann GbR

Universitätsstr. 142
D-44799 Bochum
Germany

Phone: [phone]
Mobile: [phone]
Fax: [phone]

E-mail: [hidden email]

http://www.metasieve.com/
----------------------

[burtbeckwith]

One significant benefit of using @Transactional instead of static transactional = true is that @Transactional can be applied per-method. Currently a service is either entirely transactional or entirely not. Plus, @Transactional has several attributes that allow more fine-grained configuration than what's currently available.

Burt

On Monday 27 July 2009 11:34:30 am Björn Wilmsmann wrote:

> I agree,
>
> @Transactional means less typing than static transactional = true but  
> then again, the latter is much more explicit. Moreover, anything but  
> the standard case (like the 'beautiful' example below) quickly becomes  
> so clumsy that XML configuration looks downright in comparison.
>
> Robert Fischer wrote:
>
> > I've always found piles of @'s preceeding my class title to be more  
> > confusing than enlightening: not to mention very limited in  
> > extensibility without introducing  
> > @Transactional(foo={bar={baz=true}}) and similar monstrosities.
> >
> > If I wanted that crap, I'd still be coding Java.
> >
> > ~~ Robert.
> >
> > Marcel Overdijk wrote:
> >> Personally I would prefer:
> >> @Transactional instead of:
> >> static transactional = true
> >> But I would only prefer them if I don't have to mix them.
> >> Robert Fischer wrote:
> >>> +1: I'd like to keep annotations to a minimum in Grails,  
> >>> preferably even
> >>> just leaving them to the parent language.  Graeme's cynicism about  
> >>> them is well-founded.
> >>>
> >>> ~~ Robert.
> >>>
> >>> Marcel Overdijk wrote:
> >>>> Cool! But this raises my question even further.
> >>>>
> >>>> I wouldn't like the situation to mix @Annotations, static fields  
> >>>> and
> >>>> closures to accomplish my things. I would prefer 1 approach.
> >>>>
> >>>>
> >>>>
> >>>> Burt Beckwith wrote:
> >>>>> @Transactional was implemented recently and will be in 1.2:
> >>>>> http://jira.codehaus.org/browse/GRAILS-3343
> >>>>>
> >>>>> Burt
> >>>>>
> >>>>> On Monday 27 July 2009 8:18:34 am Marcel Overdijk wrote:
> >>>>>> In Grails's early days Groovy did not supported @Annotations  
> >>>>>> yet, so
> >>>>>> using
> >>>>>> them was not an option.
> >>>>>> Another reason was to support Java 1.4.
> >>>>>>
> >>>>>> These days annotations are very common and all kind of  
> >>>>>> frameworks use
> >>>>>> them
> >>>>>> all around. Spring, Hibernate, Groovy and also JSR 303 Bean  
> >>>>>> Validation.
> >>>>>>
> >>>>>> I'm wondering what Grails's idea's are for this in the future.
> >>>>>>
> >>>>>> Take an example
> >>>>>>
> >>>>>> class CountryService {
> >>>>>>    static transactional = true
> >>>>>> }
> >>>>>>
> >>>>>> Could also be:
> >>>>>>
> >>>>>> @Transactional
> >>>>>> class CountryService {
> >>>>>> }
> >>>>>>
> >>>>>> But also using the JSR 303 Bean Validation annotations could be  
> >>>>>> used to
> >>>>>> define constraints for domain classes.
> >>>>>>
> >>>>>>
> >>>>>> I'm wondering if we you would create Grails today, would you  
> >>>>>> choose the
> >>>>>> path
> >>>>>> of using annotations?
> >>>>>
> >>> --
> >>> ~~ Robert Fischer, Smokejumper IT Consulting.
> >>> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
> >>>
> >>> Check out my book, "Grails Persistence with GORM and GSQL"!
> >>> http://www.smokejumperit.com/redirect.html
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe from this list, please visit:
> >>>
> >>>    http://xircles.codehaus.org/manage_email
> >>>
> >>>
> >>>
> >>>
> >
> > --
> > ~~ Robert Fischer, Smokejumper IT Consulting.
> > Enfranchised Mind Blog http://EnfranchisedMind.com/blog
> >
> > Check out my book, "Grails Persistence with GORM and GSQL"!
> > http://www.smokejumperit.com/redirect.html
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this list, please visit:
> >
> >   http://xircles.codehaus.org/manage_email
> >
> >
>
> --
> Viele Grüße / Best regards, Björn Wilmsmann
> Geschäftsführer / CEO
>
> ----------------------
> MetaSieve Dömges, Wilmsmann GbR
>
> Universitätsstr. 142
> D-44799 Bochum
> Germany
>
> Phone: [phone]
> Mobile: [phone]
> Fax: [phone]
>
> E-mail: [hidden email]
>
> http://www.metasieve.com/
> ----------------------

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

    http://xircles.codehaus.org/manage_email

[Sébastien Blanc]

Agree :
Annotation by exception when convention over configuration is not  
applicable

Envoyé de mon iPhone

Le 27 jul 2009 à 17:34, Luis Arias <[hidden email]> a écrit :

> I agree, annotations are probably only justified when in type safe
> mode, like when using Guice or something in a component etc..., or
> when Grails doesn't support something, it would definitely impact the
> elegance and simplicity of the current syntax.
>
> Luis
>
> On Mon, Jul 27, 2009 at 4:11 PM, Vlad
> Kasianenko<[hidden email]> wrote:
>>
>> It is quite hard to decide what should be annotation in Grails and  
>> what
>> shouldn't be. There are so many things in there that could be  
>> turned into
>> annotations. You know. But me prefer to leave everything as is. To  
>> avoid a
>> mess. IMHO.
>>
>>
>
>
> --
> Luis Arias
> [phone]
> skype : kaaloo
>
> ---------------------------------------------------------------------
> 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

[Graeme Rocher-3]

The majority of annotations can be avoided with sensible conventions.
My real problem with them is that they require 2 steps:

1) importing the annotation
2) Using the annotation

The first step more often than not requires IDE assistance to track
down the right annotation class with package etc. and import it, hence
eliminating the possibility of using a simple text editor for Grails
(which is possible a lot of the time)

This impacts the complexity of Grails, whilst with conventions and
static properties you can avoid heavy weight tools for a large portion
of the time.

On Mon, Jul 27, 2009 at 5:54 PM, Sebastien Blanc<[hidden email]> wrote:

> Agree :
> Annotation by exception when convention over configuration is not applicable
>
> Envoyé de mon iPhone
>
> Le 27 jul 2009 à 17:34, Luis Arias <[hidden email]> a écrit :
>
>> I agree, annotations are probably only justified when in type safe
>> mode, like when using Guice or something in a component etc..., or
>> when Grails doesn't support something, it would definitely impact the
>> elegance and simplicity of the current syntax.
>>
>> Luis
>>
>> On Mon, Jul 27, 2009 at 4:11 PM, Vlad
>> Kasianenko<[hidden email]> wrote:
>>>
>>> It is quite hard to decide what should be annotation in Grails and what
>>> shouldn't be. There are so many things in there that could be turned into
>>> annotations. You know. But me prefer to leave everything as is. To avoid
>>> a
>>> mess. IMHO.
>>>
>>>
>>
>>
>> --
>> Luis Arias
>> [phone]
>> skype : kaaloo
>>
>> ---------------------------------------------------------------------
>> 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
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge]

You can always inject the import transparently if needed though.
Like you inject id, version, etc.

On Mon, Jul 27, 2009 at 18:17, Graeme
Rocher<[hidden email]> wrote:

> The majority of annotations can be avoided with sensible conventions.
> My real problem with them is that they require 2 steps:
>
> 1) importing the annotation
> 2) Using the annotation
>
> The first step more often than not requires IDE assistance to track
> down the right annotation class with package etc. and import it, hence
> eliminating the possibility of using a simple text editor for Grails
> (which is possible a lot of the time)
>
> This impacts the complexity of Grails, whilst with conventions and
> static properties you can avoid heavy weight tools for a large portion
> of the time.
>
> On Mon, Jul 27, 2009 at 5:54 PM, Sebastien Blanc<[hidden email]> wrote:
>> Agree :
>> Annotation by exception when convention over configuration is not applicable
>>
>> Envoyé de mon iPhone
>>
>> Le 27 jul 2009 à 17:34, Luis Arias <[hidden email]> a écrit :
>>
>>> I agree, annotations are probably only justified when in type safe
>>> mode, like when using Guice or something in a component etc..., or
>>> when Grails doesn't support something, it would definitely impact the
>>> elegance and simplicity of the current syntax.
>>>
>>> Luis
>>>
>>> On Mon, Jul 27, 2009 at 4:11 PM, Vlad
>>> Kasianenko<[hidden email]> wrote:
>>>>
>>>> It is quite hard to decide what should be annotation in Grails and what
>>>> shouldn't be. There are so many things in there that could be turned into
>>>> annotations. You know. But me prefer to leave everything as is. To avoid
>>>> a
>>>> mess. IMHO.
>>>>
>>>>
>>>
>>>
>>> --
>>> Luis Arias
>>> [phone]
>>> skype : kaaloo
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>
>>
>>
>
>
>
> --
> Graeme Rocher
> Head of Grails Development
> SpringSource - Weapons for the War on Java Complexity
> http://www.springsource.com
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

    http://xircles.codehaus.org/manage_email

[Graeme Rocher-3]

On Mon, Jul 27, 2009 at 5:48 PM, Guillaume Laforge<[hidden email]> wrote:
> You can always inject the import transparently if needed though.
> Like you inject id, version, etc.

Which causes massive upgrade issues for existing users. For example
when groovy.lang.Category was introduced everyone who had a domain
class not in a package with the name "Category" had their apps broken.

Granted users should be using packages, but we're not prescriptive about that

Cheers

>
> On Mon, Jul 27, 2009 at 18:17, Graeme
> Rocher<[hidden email]> wrote:
>> The majority of annotations can be avoided with sensible conventions.
>> My real problem with them is that they require 2 steps:
>>
>> 1) importing the annotation
>> 2) Using the annotation
>>
>> The first step more often than not requires IDE assistance to track
>> down the right annotation class with package etc. and import it, hence
>> eliminating the possibility of using a simple text editor for Grails
>> (which is possible a lot of the time)
>>
>> This impacts the complexity of Grails, whilst with conventions and
>> static properties you can avoid heavy weight tools for a large portion
>> of the time.
>>
>> On Mon, Jul 27, 2009 at 5:54 PM, Sebastien Blanc<[hidden email]> wrote:
>>> Agree :
>>> Annotation by exception when convention over configuration is not applicable
>>>
>>> Envoyé de mon iPhone
>>>
>>> Le 27 jul 2009 à 17:34, Luis Arias <[hidden email]> a écrit :
>>>
>>>> I agree, annotations are probably only justified when in type safe
>>>> mode, like when using Guice or something in a component etc..., or
>>>> when Grails doesn't support something, it would definitely impact the
>>>> elegance and simplicity of the current syntax.
>>>>
>>>> Luis
>>>>
>>>> On Mon, Jul 27, 2009 at 4:11 PM, Vlad
>>>> Kasianenko<[hidden email]> wrote:
>>>>>
>>>>> It is quite hard to decide what should be annotation in Grails and what
>>>>> shouldn't be. There are so many things in there that could be turned into
>>>>> annotations. You know. But me prefer to leave everything as is. To avoid
>>>>> a
>>>>> mess. IMHO.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Luis Arias
>>>> [phone]
>>>> skype : kaaloo
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>>
>>>
>>>
>>
>>
>>
>> --
>> Graeme Rocher
>> Head of Grails Development
>> SpringSource - Weapons for the War on Java Complexity
>> http://www.springsource.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email

[Guillaume Laforge-2]

On Mon, Jul 27, 2009 at 19:07, Graeme
Rocher<[hidden email]> wrote:
> On Mon, Jul 27, 2009 at 5:48 PM, Guillaume Laforge<[hidden email]> wrote:
>> You can always inject the import transparently if needed though.
>> Like you inject id, version, etc.
>
> Which causes massive upgrade issues for existing users. For example
> when groovy.lang.Category was introduced everyone who had a domain
> class not in a package with the name "Category" had their apps broken.
>
> Granted users should be using packages, but we're not prescriptive about that

Yup, very good point about the namespace pollution.
Usually, I guess they'd be kinda cross-cutting so shouldn't be often
seen in users domain classes (although Category is a good
counter-example).
I've a bit got the feeling annotations would be nicer in some areas,
but in other places, like custom validators, and other things,
annotations would be too limiting for Grails, and would make stuff
uglier. So I've got mixed feelings about this.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

    http://xircles.codehaus.org/manage_email

[Björn Wilmsmann-2]

Hello Burt,

maybe, this could be done by naming conventions? I'm thinking along  
the lines of methods that end in 'Transactional' and take an  
additional options parameter: someMethodTransactional (def options =  
[:]) { ... }.

Burt Beckwith wrote:

> One significant benefit of using @Transactional instead of static  
> transactional = true is that @Transactional can be applied per-
> method. Currently a service is either entirely transactional or  
> entirely not. Plus, @Transactional has several attributes that allow  
> more fine-grained configuration than what's currently available.
>
> Burt
>
> On Monday 27 July 2009 11:34:30 am Björn Wilmsmann wrote:
>> I agree,
>>
>> @Transactional means less typing than static transactional = true but
>> then again, the latter is much more explicit. Moreover, anything but
>> the standard case (like the 'beautiful' example below) quickly  
>> becomes
>> so clumsy that XML configuration looks downright in comparison.

--
Best regards,
Bjoern Wilmsmann

[Graeme Rocher-3]

2009/7/27 Björn Wilmsmann <[hidden email]>:
> Hello Burt,
>
> maybe, this could be done by naming conventions? I'm thinking along the
> lines of methods that end in 'Transactional' and take an additional options
> parameter: someMethodTransactional (def options = [:]) { ... }.

We could do it with a DSL, but Spring already provided the annotation
based approach which was easy to add support for.

Cheers

>
> Burt Beckwith wrote:
>
>> One significant benefit of using @Transactional instead of static
>> transactional = true is that @Transactional can be applied per-method.
>> Currently a service is either entirely transactional or entirely not. Plus,
>> @Transactional has several attributes that allow more fine-grained
>> configuration than what's currently available.
>>
>> Burt
>>
>> On Monday 27 July 2009 11:34:30 am Björn Wilmsmann wrote:
>>>
>>> I agree,
>>>
>>> @Transactional means less typing than static transactional = true but
>>> then again, the latter is much more explicit. Moreover, anything but
>>> the standard case (like the 'beautiful' example below) quickly becomes
>>> so clumsy that XML configuration looks downright in comparison.
>
> --
> Best regards,
> Bjoern Wilmsmann
>
>
>
>

--
Graeme Rocher
Head of Grails Development
SpringSource - Weapons for the War on Java Complexity
http://www.springsource.com

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

    http://xircles.codehaus.org/manage_email

[Marcel Overdijk]

Guillaume,

This is exactly how I feel also.
I also think this is a good discussion to find out how the community thinks about it.

Ultimate solution would be to support them both off course. I understand this would mean more effort to maintain the code base.
Similar like Spring configuration can almost entirely be done using Annotations; but if you don't like them you can still use XML configuration.

But there are indeed also area's which will be difficult to implement using annotations like the custom validator you refer to.

I have no solution, but again, I like this discussion.

One side remark.
I would not like to mix annotations and static properties, and with http://jira.codehaus.org/browse/GRAILS-3343 this is actually happening.


Cheers,
Marcel

glaforge wrote

I've a bit got the feeling annotations would be nicer in some areas,
but in other places, like custom validators, and other things,
annotations would be too limiting for Grails, and would make stuff
uglier. So I've got mixed feelings about this.

--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one