Breaking changes in lift-record 2.0-SNAPSHOT - Optional fields

[Ross Mellgren]

I just committed a change to lift-record in 2.0-SNAPSHOT that will possibly (probably?) break your build if you use it.

This change makes it possible to have any record field be optional -- that is, Box[MyType]. You use it like this:

object MyRecord extends Record[MyRecord] {
object myNormalField extends StringField(this, 100)
object myOptionalField extends StringField(this, 100) {
override def optional_? = true
override def defaultValueBox = Empty
override def defaultValue = "nothin"
}
}

val r: MyRecord

r.myNormalField.set("Hello") // as before the change
r.myOptionalField.setBox(Empty)

r.myNormalField.value == "Hello" // as before
r.myNormalField.valueBox == Full("Hello")
r.myOptionalField.valueBox == Empty
r.myOptionalField.value == "nothin" // because defaultValue was used to give back something

As part of this change, the semantics for field errors has changed somewhat -- hopefully, to be more consistent.

Previously if you tried to set a field and checkCanWrite_? returned false then an internal flag "valueCouldNotBeSet" on the field will be raised which makes that field generate a validation error when validate is called on the record. In addition, some fields (but not all) would raise the same flag and return Failure or Empty from setFromString or setFromAny upon being given an invalid value.

With this change, all types of failure to set now result in the field value becoming a Failure. setFromAny, setFromString, and setBox all return that Failure, while set will return defaultValue (due to its return type.)

validators and set filters have had their types changed to Boxed equivalents.

And finally, I made consistent the setFromAny methods of all the built-in field types so that they all follow the same contract. For setFromAny it's essentially accept one of MyType, Box[MyType], Option[MyType], or List[MyType] as well as null, with a default to convert an unknown input to string and use setFromString. For setFromString, it is as before, except if the field is optional_? and the empty string is passed in, that's treated as Empty.

As I'll mention in another message, I also pushed lift-couchdb to master. I ran the unit tests that I wrote for that, but that doesn't give me full confidence that all the fields are entirely bug free. Similarly I did not test the form generation. If anybody runs into any issues please let me know and I'll fix it as soon as I can. And of course if it causes too much breakage we can revert it back out.

-Ross

[harryh]

What is the advantage of doing it this way as opposed to having a
collection of Field types who's value is a Box[Whatever]
(OptionalStringField, OptionalLongField, etc).

I'm finding the e-mail you sent to the list moderately confusing.
Maybe it's just that more explanation is needed?

-harryh

[Ross Mellgren]

Originally I had implemented this like you suggest, with separate field types. Marius reviewed it and preferred it to be baked into the basic field type.

The advantages over that method are:
- Not requiring 2x the number of field types everywhere. For example any record implementation that extends fields needs double (e.g. DBIntField, DBOptionalIntField)
- Less code
- Centralizes error handling.

Fields that aren't optional should act mostly the same as they did, modulo validators and set filters.

Let me know what you'd like described better. I can go into the details of how it's implemented maybe? Or do you want more examples? I'd be happy to clarify what the change is.

-Ross

P.S. here's the RB link, in case you'd like to take a look at the older version, or what have you

http://reviewboard.liftweb.net/r/191/

> --
> You received this message because you are subscribed to the Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com.
> To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
>

[Marius]

Excellent work Ross !