[Haskell-cafe] The Good, the Bad and the GUI

[Raphaël Mongeau]

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 at power.com.pl>:

> On 14.08.2014 16:44, ok at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
Viva Cila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140814/874f6b57/attachment.html>