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/ On Feb 12, 2010, at 12:34 AM, harryh wrote: > 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. > -- 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.
