[web-devel] Kick-off discussion: Yesod 0.9

[Michael Snoyman]

On Wed, Jun 1, 2011 at 7:02 PM, Justin Greene <nephesh.chifire at gmail.com> wrote:
>> Right now, you can apply whatever validation you want to an individual
>> fields and display the error messages inline. For complex scenarios,
>> I'm not quite certain what an interface (both programming interface
>> and UI) would look like for assigning these error messages inline.
>> Short of that, it seems outside the scope of the form package itself
>> to validate such interactions. For example, you could always write
>> code along the lines of:
>>
>> ((res, form), enctype) <- runFormPost ...
>> case res of
>>   FormSuccess x ->
>>       case complexTest x of
>>           Left e -> showFormWithErrMsg form e
>>           Right y -> onSuccess y
>>   _ -> showFormWithoutErrMsg form
>
> My only comment about this is that it creates a bad user experience.  If my
> form type binding is not successful on all fields then this complex
> validation scenario will not fire.  This makes it so the user has to get
> past one set of error messages, and then move on to the next set.  Ideally
> they would receive all error messages at once that are possible to validate
> at the time.  While it may not be easy in haskell to accomplish this, it's
> definitely something that needs to be considered imo.
>
> An example form:
> CheckBox
> FirstName
> Date of Birth
>
> If a user selects the checkbox then the first name is now required.
> However, they entered an incorrectly formatted date of birth.  We have
> enough information to fire to the complex validator in this scenario at the
> same time as showing an error about an improper date for the date of birth
> field.  The above example wouldn't do this though, it would first show an
> error about the date of birth being invalid, and then after that is fixed it
> would show the error about the first name being required.
>
> I realize haskell makes this scenario challenging, so it may not be worth
> your time to optimize for it, but I think any advanced forms framework
> should consider it.
>
> I would love to help design this api, but my hobby time is going to be all
> used up for a long while (trying to bootstrap a startup in my spare time).
> I will say that I think template haskell is probably the only way to
> actually fulfill these types of requirements in haskell (though I could
> easily be wrong about that).

I think the solution here is to create a combined field for checkbox +
name field. In the Applicative case, this would constrain you to
having both widgets display in the same table cell/div, but I think
this is acceptable: Applicatives are meant for "standard" layouts. If
you want something more custom, you'll end up with a Monadic form
providing a "FormResult (Bool, Text)".

Obviously, the library isn't going to do *exactly* what you're looking
for in every case (unless you're in the fortunate position like me of
having written the library), but I think there's enough power
available to cover even complicated cases in a safe way. I think TH
isn't necessary here, though its usage may allow for significantly
more concise definitions.

Michael