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 On Feb 11, 11:49 pm, Ross Mellgren <[email protected]> wrote: > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
