Grails 2.3 Data Binding, String Trimming And Null Conversions

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

Grails 2.3 Data Binding, String Trimming And Null Conversions

Jeff Scott Brown-2
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

longwa
I think the trim() and null translation sounds like a really good default. Like you said, it's rare to want to have empty strings or a bunch of tabs and spaces. I like the idea of just having one way, @BindUsing, to override this behavior on a field-by-field basis. I suppose you could create some default FormattedValueConverter with a name of like 'no-trim' that could use the @BindUsing('no-trim') syntax.

-Aaron


On Tue, May 28, 2013 at 5:09 PM, Jeff Brown <[hidden email]> wrote:
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown

Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

longwa
Actually, I guess it would be @BindFormat('no-trim'), not @BindUsing. Would the @BindFormat also be capable of intercepting the default trim behavior? 

Also, can @BindFormat take a list; something like @BindFormat(['uppercase', 'somethingElse'])? I'm not sure if that's needed, just trying to think through the ways to use this thing.


On Tue, May 28, 2013 at 8:09 PM, Aaron Long <[hidden email]> wrote:
I think the trim() and null translation sounds like a really good default. Like you said, it's rare to want to have empty strings or a bunch of tabs and spaces. I like the idea of just having one way, @BindUsing, to override this behavior on a field-by-field basis. I suppose you could create some default FormattedValueConverter with a name of like 'no-trim' that could use the @BindUsing('no-trim') syntax.

-Aaron


On Tue, May 28, 2013 at 5:09 PM, Jeff Brown <[hidden email]> wrote:
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown


Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

rosenfeld
In reply to this post by Jeff Scott Brown-2
While I agree that trim and converting empty to null are sensible defaults, I believe [blank: true] is not, since it is not compatible with the other defaults.

That's why I proposed that the default for blank becomes false, and then, if blank is explicitly set to true, then converting empty to null shouldn't be performed by the default data binding mechanism.

Anyway, I believe data binding is being much improved on Grails 2.3, congrats.

Cheers,
Rodrigo.

Em 28-05-2013 18:09, Jeff Brown escreveu:
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown

Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

sergiomichels
Is there any use case of blank:true, leaving an attribute with spaces not trimmed?

--
Sérgio Michels


On Wed, May 29, 2013 at 10:25 AM, Rodrigo Rosenfeld Rosas <[hidden email]> wrote:
While I agree that trim and converting empty to null are sensible defaults, I believe [blank: true] is not, since it is not compatible with the other defaults.

That's why I proposed that the default for blank becomes false, and then, if blank is explicitly set to true, then converting empty to null shouldn't be performed by the default data binding mechanism.

Anyway, I believe data binding is being much improved on Grails 2.3, congrats.

Cheers,
Rodrigo.

Em 28-05-2013 18:09, Jeff Brown escreveu:
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown


Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

rosenfeld
Yes, in my application we log the time a user spent on the application.

In some cases, people will forward the costs of the application to specific clients they're working for, based on the time they use the tool for that user, although this is not common.

For that, we have a not null column that is set to an empty string in case there's no special client they're working for (the commonest case). We preferred to use a blank string instead of a null value due to some unique indexes over multiple columns that we have in our table. Different DB vendors treat null in multi-column unique constraints in different ways, so we didn't want to bother about that and decided to use a blank string in case no client is specified (a regular user using our tool).

On the other side, I never wanted a column to store a spaces-only string.

Cheers,
Rodrigo.

Em 29-05-2013 11:32, Sergio Michels escreveu:
Is there any use case of blank:true, leaving an attribute with spaces not trimmed?

--
Sérgio Michels


On Wed, May 29, 2013 at 10:25 AM, Rodrigo Rosenfeld Rosas <[hidden email]> wrote:
While I agree that trim and converting empty to null are sensible defaults, I believe [blank: true] is not, since it is not compatible with the other defaults.

That's why I proposed that the default for blank becomes false, and then, if blank is explicitly set to true, then converting empty to null shouldn't be performed by the default data binding mechanism.

Anyway, I believe data binding is being much improved on Grails 2.3, congrats.

Cheers,
Rodrigo.

Em 28-05-2013 18:09, Jeff Brown escreveu:
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown



Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

rosenfeld
Sorry, I was re-reading your question and I think I misread it...

No, it doesn't make sense for me that blank would mean a string composed only by spaces. My own definition of blank is so that BLANK === "" and only that.

Also, I don't see any use cases for a spaces-only string in any attribute.

Em 29-05-2013 13:21, Rodrigo Rosenfeld Rosas escreveu:
Yes, in my application we log the time a user spent on the application.

In some cases, people will forward the costs of the application to specific clients they're working for, based on the time they use the tool for that user, although this is not common.

For that, we have a not null column that is set to an empty string in case there's no special client they're working for (the commonest case). We preferred to use a blank string instead of a null value due to some unique indexes over multiple columns that we have in our table. Different DB vendors treat null in multi-column unique constraints in different ways, so we didn't want to bother about that and decided to use a blank string in case no client is specified (a regular user using our tool).

On the other side, I never wanted a column to store a spaces-only string.

Cheers,
Rodrigo.

Em 29-05-2013 11:32, Sergio Michels escreveu:
Is there any use case of blank:true, leaving an attribute with spaces not trimmed?

--
Sérgio Michels


On Wed, May 29, 2013 at 10:25 AM, Rodrigo Rosenfeld Rosas <[hidden email]> wrote:
While I agree that trim and converting empty to null are sensible defaults, I believe [blank: true] is not, since it is not compatible with the other defaults.

That's why I proposed that the default for blank becomes false, and then, if blank is explicitly set to true, then converting empty to null shouldn't be performed by the default data binding mechanism.

Anyway, I believe data binding is being much improved on Grails 2.3, congrats.

Cheers,
Rodrigo.

Em 28-05-2013 18:09, Jeff Brown escreveu:
The default behavior in Grails 2.3 is to trim strings during data binding.  In addition to that, another default behavior is to convert empty strings (strings with nothing in them, not even spaces) to null during data binding.  Those 2 things happen in that order so if you bind a String with nothing in it but spaces, the default behavior is to bind null because the String will be trimmed and then since it is empty it will be converted to null.  This is a sensible default.  There are separate config properties for disabling either of those behaviors.

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=false

All of that is documented in the user guide.

http://jira.grails.org/browse/GRAILS-10142 proposes that maybe the framework should support some mechanism to turn that off on a per property basis.  In particular one thing that was suggested is to not do the null conversion for any property that is explicitly configured with blank:true.  I am leaning toward not wanting to do that but would like to open it up for discussion.  Part of the reason I am not crazy about the idea is it is one more variable in the mix.  Right now the rules are very easy to understand.  The default behavior is what makes the most sense, most of the time.  It is easy to turn the trimming behavior off.  It is easy to turn the null conversion behavior off.

One way to deal with turning the behavior off for a particular property is to use the new @BindUsing annotation.  The @BindUsing annotation is one of several new ways that Grails 2.3 allows the application to participate in the data binding process.  If you annotate a property with @BindUsing you get to provide a Closure that dictates what gets bound.  You have access to the whole binding source (a Map) so you can do complicated things that might depend on multiple values in the binding source if you like.  For just turning off the null conversion you could do something like this:

class Widget {
    @BindUsing({ obj, source -> source['name'].trim() })
    String name
}


That closure retrieves the 'name' value from the binding source, invokes trim() on it and the result of that is what is returned from the closure so that is what gets bound to the name property.  It is a little tedious but not something that should be done very often.  The majority of applications are going to do that zero times.  There will be lots of interesting ways that some applications take advantage of @BindUsing.  This is just 1 simple thing you might use it for.

We could introduce special annotations that turn on/off things like string trimming and null conversion but that is just 1 more bit of clutter in the runtime and the source code.  We could introduce some syntax in Config.groovy to turn those things on/off on a per class or per property basis but again, just more stuff to execute and reason about, compared to the pretty simple thing we have now.

I am asking for input.  If you care about how any of this ends up, please share your thoughts.  If we are going to make any changes for this I would like to do it soon.  We are closing in on M2 pretty quickly.  It is a milestone and we can still make changes after it is released but the more details that we get covered in the milestones the better off we will be when RCs are built.

Thanks for your time.



JSB
--
Jeff Brown




mzp
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

mzp
In reply to this post by Jeff Scott Brown-2
In our 2.2.4 app we have the case where nullable: true, blank: false. When moving to 2.3.x tests break unless we set
// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=true
grails.databinding.trimStrings=false

However with this setting we lose the trimming of Strings that are padded with spaces. So it seems like our only option at this point is to now update every String field with @GrailsUsing or @GrailsFormat annotation which would trim non blank Strings. Or change the config setting to

// grails-app/conf/Config.groovy
grails.databinding.convertEmptyStringsToNull=false
grails.databinding.trimStrings=true

and update every non String field with @GrailsUsing or @GrailsFormat annotation which would convert empty String to null.

It just seems like to get back to 2.2.x behavior we have to do a lot of extra work. It would be nice if there was a simpler way to achieve this.
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

Jeff Scott Brown-2


On February 3, 2014 at 12:22:05 PM, mzp ([hidden email]) wrote:

>  
> In our 2.2.4 app we have the case where nullable: true, blank:  
> false. When
> moving to 2.3.x tests break unless we set
> // grails-app/conf/Config.groovy
> grails.databinding.convertEmptyStringsToNull=true
> grails.databinding.trimStrings=false
>  
> However with this setting we lose the trimming of Strings that  
> are padded
> with spaces. So it seems like our only option at this point is to  
> now update
> every String field with @GrailsUsing or @GrailsFormat annotation  
> which would
> trim non blank Strings. Or change the config setting to
>  
> // grails-app/conf/Config.groovy
> grails.databinding.convertEmptyStringsToNull=false
> grails.databinding.trimStrings=true
>  
> and update every non String field with @GrailsUsing or @GrailsFormat  
> annotation which would convert empty String to null.
>  
> It just seems like to get back to 2.2.x behavior we have to do a lot  
> of
> extra work. It would be nice if there was a simpler way to achieve  
> this.
>  

I think that the only behavior that you can’t get back from 2.2.x is having the nullable constraint affect data binding and we did away with that on purpose.  Is that the only behavior you can’t easily get back or is there something else?




JSB

--
Jeff Scott Brown
[hidden email]

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


mzp
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

mzp
So far the only other things that appears to be behaving differently is the date picker. The params are coming back with different values than in 2.2.4.

Regarding the data binging string trimming and null conversions, we decided to change our constraints to not have blank: false, so that we can make use the new data binding feature.
mzp
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

mzp
In reply to this post by Jeff Scott Brown-2
So it seems like there was a change with how the value for dates being set by the grails date picker is being set when params get reset to the multi dimensional hash structure. it seems like the date value is null instead of 'date.struct' as it used to be when you access it like params.someDomainName['dateCreated]['value']
Reply | Threaded
Open this post in threaded view
|

Re: Grails 2.3 Data Binding, String Trimming And Null Conversions

Jeff Scott Brown-2


On February 11, 2014 at 10:24:01 AM, mzp ([hidden email]) wrote:
>  
> So it seems like there was a change with how the value for dates  
> being set by
> the grails date picker is being set when params get reset to the  
> multi
> dimensional hash structure.

I don’t know what that means but if you file a JIRA with a simple sample app which contains the behavior that you are concerned about along with a description of the behavior that you expected, I will be happy to take a look at that.



JSB

--
Jeff Scott Brown
[hidden email]

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