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
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