I'd strongly suggest: 1. All should return Box. In case of parsing failure for example return a Failure. 2. If a param is null, inside your method use (Box !! param) which would give you an Empty if param is null.
We should not assume dumb default values for input that doesn't make sense. Br's, Marius On Jan 15, 4:38 am, Naftoli Gugenheim <[email protected]> wrote: > As suggested I am with G-d's help working on a new > net.liftweb.http.ConversionRules object, to contain factories for parsers and > formatters for date, date-time, time java.util.Date objects. Then > LiftRules.formateDate and .parseDate would be deprecated I suppose. > One question is how to deal with null. The LiftRules implementation for > formatDate replaces null with new Date(0L), and parseDate returns Empty for a > null input. > 1. Should these functions worry about null? Maybe it's the caller's > responsibility, such as net.liftweb.mapper.MappedDate. > 2. If they should think about null, parseXXX returns a Box anyway because a > string may not parse, and null certainly doesn't parse and should thus return > Empty. However how should formatXXX deal with null? Here are some > suggestions; any others are welcome. > (a) Return an empty string - "" > (b) Return something like " (no selection)" etc. > (c) formatXXX should also return a Box, which would be Empty for null > (d) Behave as though new Date(0L) was passed in > (e) Behave as though new Date was passed in
-- 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.
