Changing the default list method

the default list method in generated controllers looks like this:

<code>
    @Property list = {
        [ exampleList: Example.list( params ) ]
    }
</code>

This can be changed to return results however you need. For example, to execute an HQL statement to return the results in reverse order of id, use the following:

<code>
    @Property list = {
        [ exampleList: Example.findAll( "from Example order by id desc", params ) ]
    }
</code>

Understanding Acegi’s FilterSecurityInterceptor and URL matching

The ‘CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON’ parameter to FilterSecurityInterceptor means exactly that – URLs are converted to lower case for comparison with the patterns that you define.

If you use CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON, then make sure all the URL patterns you specify are also in lower case, otherwise you will never get a match. This seems obvious, but it took me several hours of trial and error before I spotted what was not working in my configuration.

For example, take this snippet of configuration:

<code>
    &lt;bean id="filterInvocationInterceptor" class="org.acegisecurity.intercept.web.FilterSecurityInterceptor"&gt;
        &lt;property name="authenticationManager"&gt;
        &lt;ref bean="authenticationManager"/&gt;&lt;/property&gt;
        &lt;property name="accessDecisionManager"&gt;
        &lt;ref bean="accessDecisionManager"/&gt;&lt;/property&gt;
        &lt;property name="objectDefinitionSource"&gt;
            &lt;value&gt;
                CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
                PATTERN_TYPE_APACHE_ANT
                /acegilogin.jsp*=ROLE_ANONYMOUS, ROLE_ADMIN
                /=ROLE_ANONYMOUS, ROLE_ADMIN
                /index.jsp=ROLE_ANONYMOUS, ROLE_ADMIN

                /item/show/**=ROLE_ANONYMOUS, ROLE_ADMIN
                /item/list/**=ROLE_ANONYMOUS, ROLE_ADMIN
                /item/doSomeOtherThing=ROLE_ANONYMOUS, ROLE_ADMIN
                ...
    &lt;/bean&gt;
</code>

The URL ‘/item/doSomeOtherThing’ is never going to be matched, since the incoming URLs for comparison are converted to lowercase by the CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON instruction.

Handling validation on Entity properties

Grails GORM (Grails Object Relational Mapping) allows you to define a number of validation rules that are carried through to your view when entering data.

For example with following simple Entity:

<code>
class Test1 { 
    Long id
    Long version
    String string1
    Long testLong
    Float float1
	
    def constraints = {
        string1(blank:false)
        testLong(nullable:false,blank:false)
        float1(nullable:false,blank:false)
	}
...
}
</code>

The ‘constraints’ section defines the rules on the properties on this Entity – the rules are a comma separated list of name/value pairs for the rules to be applied. Notice the ‘blank’ only works on String properties. To require a value for any other property type, use ‘nullable:false’.

Here are some further self-explanatory examples from the online Grails docs:

<code>

   def constraints = {
          login(length:5..15,blank:false,unique:true)
          password(length:5..15,blank:false)
          email(email:true,blank:false)
          age(min:new Date(),nullable:false)
   }
</code>