Would't this be a good solution to the partial null fields probleme? --The field name and the value type Field = (String,String) --The form informations we get from the client type FormResult = [Filed] --An error message to send to teh client type FormError = String data Person = Person { firstName :: String ,lastName :: String ,birthDate :: Date ,height :: Int } type PersonParseResult = Either FormError Person --When receiving data froom the client you call this function and return the error to the client or continue normaly getPersonneFromForm :: FormResult -> PersonParseResult --You could go furter and do this: class FromForm a where fromForm :: FormResult -> Either FormError a instance FromForm Person where fromForm a = getPersonneFromForm a --And then you could do this: thisFunctionGetAForm :: FormResult -> HTTPResponse thisFunctionGetAForm f = case (fromForm f) :: PersonParseResult of Left a -> toHTTPResponse "The form is invalid" Right a -> toHTTPResponse "Ok, we got you" 2014-08-14 11:11 GMT-04:00 Wojtek Narczyński <wojtek@power.com.pl>:
On 14.08.2014 16:44, ok@cs.otago.ac.nz wrote:
It may be familiar, it may be popular, but the answer is beyond any reasonable question simply WRONG.
The exactly advantage of a purpose built app over a spreadsheet is that it would not let you save the invoice in this state. Indeed, perhaps it is a good idea to tell the users that this sum is not their final value. For example display a marijuana leaf next to it. Although, I would rather use color for that.
(The emphasis on NEVER is mine.) I guess now we know one
more reason why spreadsheet errors are ubiquitous: the interface is broken by design.
I like spreadsheets, but they are not an answer to every need.
I have no idea what is customary, but I for d--n sure would not use a spreadsheet to do it! (This being a Haskell mailing list, I would investigate the abilities of hLedger.)
Sorry, hledger is a double entry accounting system, it does not issue invoices.
So in the end you admit that my "design" (scratch, rather) might be what
young people might like?
On the contrary. You are specifying a design that lets invalid data enter into computations. I'm saying they would like a design that stops invalid data as early as possible. This is close in spirit to the Foo/FooBuilder distinction, where a Foo is never allowed to be in an invalid state.
Pardon me, but are you "young people"?
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Viva Cila