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