Wojtek Narczyński wrote:
Heinrich Apfelmus wrote:
Wojtek Narczyński wrote:
I would really like to see a complex web form (think Facebook, VAT Invoice, Tax forms) done in FRP. The harsh reality is that FRP for GUIs still has to prove that its utility reaches beyond the game of Pong.
Like this?
http://www.haskell.org/haskellwiki/Reactive-banana/Examples#crud
It's still a toy model, but I think it captures the essential difficulties. A full blown tax form would just be more of the same.
Is it live anywhere? I'd like to test it for HTML injection.
It's actually a wxHaskell applications, the screenshot is from a temporary but now deprecated adaption to Threepenny-gui. So, the issue of HTML injection does not arise. (It would not arise in a HTML context either, because of strong typing.) The key point about this CRUD example, which is not shown in the screenshot, is that it has immediate feedback: values in the list box change as you type. Editing the name on the right-hand side will change the name in the list box, and changing the filter will immediately update the available names in the list box.
The #1 difficulty is validation. Is there any in this example? I can't see any. This really does not qualify as a complex web form.
You'll get _exponentially_ more of the same. See paper "Plato: A Compiler for Interactive Web Forms", http://www.cs.uic.edu/~hinrichs/papers/hinrichs2011plato.pdf
Validation is mainly a question of *how* to present feedback about invalid data to the user -- for instance by making invalid data impossible to enter, or by showing errors in red and retaining the last correct value, etc. I would consider this as a narrow part of GUI programming. For me, GUI programming is about user interfaces and interaction design in general, including zoom, animation, games, and so on. FRP is a better tool at this than the traditional event-based style. Of course, in the context of form validation, FRP would be a building block: It does not give any advice on which feedback to present to the user, but it does allow you to quickly implement whatever feedback you have chosen to present. Still, even for the more narrow problem of forms and input validation, I don't see how you arrive at your claim that "Haskell is however not great for GUIs". This seems like a problem that can be solved with a traditional DSL approach, and I would be surprised if Haskell were unsuitable as a host language, contrary to what your claim seems to imply. Whether DSLs along these lines are already available is another question. Alberto mentioned one, another one would be [1]. [1]: http://www.sandr.dds.nl/publications/FForms.pdf Best regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com