[Haskell-cafe] [web-devel] The promising world of Monadic formlets
Alberto G. Corona
agocorona at gmail.com
Sat Jun 22 18:07:45 CEST 2013
I have a similar problema with the ids of formlets of different branches of
execution. For example in the first case statement the branch represented
can be one or the other depending on the previous user response.
The identifiers of each branch must be different or else, the
server application will be confused by misreading states (values in my
case) of different branches. For this purpose each branch has a "pageflow"
call that add a new prefix to the identifiers and initialize a counter used
to compose a sequence of suffixes for each branch, so that each element has
an unique identifier and the identifiers of one branch do not collide with
the ones of the other branch. Is this similar and hopefully applicable to
your problema?
2013/6/22 Anton Tayanovskyy <anton.tayanovskyy at gmail.com>
> Our team at IntelliFactory has worked with "monadic" formlets for a while,
> we call them "flowlets", in the context of WebSharper/F#. We even have an
> obscure paper out there about it. The difference with your approach is that
> we are working directly with DOM nodes and imperative widgets to execute
> entirely in the browser in JavaScript. This makes for nice looking demos,
> but unfortunately comes with a price. With imperative widgets, identity
> matters. If you work with console text output or re-creating an HTML
> document, you simply model what you present to the user with a tree, with
> inductively defined equivalence. In DOM world, however, two HTML trees with
> an input textbox may serialize equivalently but be distinct, in a sense
> that the textboxes have distinct identity and hidden state (such as focus),
> and substituting one for another will be noticed by the user. To this day I
> have not been able to come up with a convincing simple model and a notion
> of equivalence that would take that into account and allow to prove monadic
> laws to hold for the flowlet combinators. I suspect it should be possible
> though and even likely done already :)
>
> Thanks,
>
> --A
>
>
>
> On Sat, Jun 22, 2013 at 12:49 AM, Daniel Frumin <difrumin at gmail.com>wrote:
>
>> This looks interesting. I'll be following the development of it
>>
>> On Jun 20, 2013, at 2:56 PM, "Alberto G. Corona " <agocorona at gmail.com>
>> wrote:
>>
>> Here is the example with better rendering and additional information as
>> well as some identifies issues to be solved.
>>
>>
>> http://haskell-web.blogspot.com.es/2013/06/the-promising-land-of-monadic-formlets.html
>>
>> And I made strong statements there.
>>
>> What do you think? If you have questions or want to be involved in
>> the development of this and other related concepts, please send me a
>> message.
>>
>>
>> 2013/6/20 Alberto G. Corona <agocorona at gmail.com>
>>
>>> I don´t know how, but the google mail has changed the applicative
>>> functor operator after (,) Left and Rigth by "<-".
>>>
>>>
>>>
>>>
>>> 2013/6/19 Alberto G. Corona <agocorona at gmail.com>
>>>
>>> Hi,
>>>>
>>>> This is just to let you know the promising results of some
>>>> experimentation:
>>>>
>>>> Formlets are about applicative instances, but what about monadic
>>>> instances? What a Monad instance of formlets means? I recently experimented
>>>> with this and the results are very interesting and powerful- It mixes the
>>>> best of web forms, with the flexibility of console applications. ???!!!!!!
>>>>
>>>>
>>>> Althoug this example is for the formlets of the MFlow
>>>> <https://github.com/agocorona/MFlow>framework , it can be ported to
>>>> other formlet implementations. Although the MFLow formlets include web
>>>> formatting that is not supported in other formlets implementations. Static
>>>> HTML templating don´t work well with monadic formlets, so it is important
>>>> to include the formatting as a part of the computation:
>>>>
>>>> import MFlow.Wai.Blaze.Html.All
>>>>
>>>> dynamicForm= wform $ do
>>>> (n,s) <- (,) <- p << "Who are you?"
>>>> ++> getString Nothing <! hint "name" <++ br
>>>> <*> getString Nothing <! hint "surname" <++ br
>>>> <** submitButton "ok" <++ br
>>>>
>>>> flag <- b << "do you " ++> getRadio[radiob "work?",radiob
>>>> "study?"] <++ br
>>>>
>>>> r<-case flag of
>>>> "work" -> pageFlow "l"
>>>> $ Left <- b << "do you enjoy your work? "
>>>> ++> getBool True "yes" "no"
>>>> <** submitButton "ok" <++ br
>>>>
>>>> "study"-> pageFlow "r"
>>>> $ Right <- b << "do you study in "
>>>> ++> getRadio[radiob "University"
>>>> ,radiob "High School"]
>>>>
>>>> p << ("You are "++n++" "++s) ++>
>>>> case r of
>>>> Left fl -> p << ("You work and it is " ++ show fl ++ " that
>>>> you enjoy your work")
>>>> ++> noWidget
>>>>
>>>> Right stu -> p << ("You study at the " ++ stu)
>>>> ++> noWidget
>>>>
>>>>
>>>> hint s= [("placeholder",s)]
>>>> onClickSubmit= [("onclick","this.form.submit()")]
>>>> radiob s n= text s ++> setRadio s n <! onClickSubmit
>>>>
>>>> Here wform, getBool, getString , getRadio etc are formlet elements
>>>>
>>>> The first sentence is an applicative composition that generate a 2
>>>> tuple, to show that applicative and monadic can be mixed. the operations
>>>> ++> add html to the formlet. the operatior <! add attributes to the formlet
>>>> element.. noWidget is a dumb formlet that does not validate.
>>>>
>>>> The second monadic statement is an election between two options. The
>>>> beauty of the monadic instance is that the rest of the form can vary
>>>> depending on the previous answers. Since the formlets validate the input,
>>>> unless the election is made, the radio will not validate, so the monadic
>>>> execution will be aborted beyond any unanswered question, so nothing will
>>>> appear after the question. The rest of the form will appear when the user
>>>> choose one of the two options. once one or the other option is chosen, then
>>>> another binary question is presented. (either he likes his work or where he
>>>> study). When the questions are finised, the results are presented.
>>>> I hope that you get the idea. The benefit is not only the familiar
>>>> coding and presentation of a sequential console application: Since the form
>>>> encloses all the fields, At any time the user can change previous inputs
>>>> and the form will reflect these changes. For example if the user change
>>>> from work to study (second statements) the "where do you study will appear
>>>> and the work related questions and answers will disappear. That is
>>>> wonderfully useful for heavily interactive applications.
>>>>
>>>> There is a problem however and it is the issue of the formlet
>>>> identifiers. Unlike in an applicative presentation, now the number and type
>>>> of the formlets will vary, so the response to a previous form create a new
>>>> kind of form, and the post response can be misinterpreted. To avoid that ,
>>>> the pageFlow call creates fixed field labels for each branch of execution.
>>>>
>>>> I will release a version of MFlow that support this kind of monadic
>>>> composition of fomlets, but In essence it is nothing but to add Monad
>>>> instance to formlets. A single server procedure, that executes the formlet
>>>> code can support all the interaction so any framework can do it. The
>>>> usability of that is huge:It is possible to interact in a web page in a
>>>> console style with questions and answers with the versatitly of a dynamic
>>>> foms: Any modification in the form change the subsequent flow of
>>>> interaction. Another application of this monadic style is to ease multistep
>>>> processes such are registration, check-out and payment ad so on. Even a
>>>> entire interactive dynamic application can be coded in a single page.
>>>>
>>>> And no javascript is needed!.
>>>>
>>>>
>>>> To run this formlet in MFlow:
>>>>
>>>> main=do
>>>> addMessageFlows
>>>> [("" , transient $ runFlow $ ask dynamicForm )]
>>>>
>>>> wait $ run port waiMessageFlow
>>>>
>>>>
>>>> This video show how the presentation of this example vary with the user
>>>> input:
>>>>
>>>> http://youtu.be/DryBQc9agFg
>>>>
>>>>
>>>> I hope that you find the idea interesting. If you want to experiment
>>>> with this in MFlow, I have to say that the implementation of this feature
>>>> is in an early stage. The code is in the head branch
>>>>
>>>> https://github.com/agocorona/MFlow/tree/head
>>>>
>>>>
>>>>
>>>> Alberto.
>>>>
>>>
>>>
>>>
>>> --
>>> Alberto.
>>>
>>
>>
>>
>> --
>> Alberto.
>>
>> _______________________________________________
>> web-devel mailing list
>> web-devel at haskell.org
>> http://www.haskell.org/mailman/listinfo/web-devel
>>
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>
>
> --
> Kind Regards,
> Anton Tayanovskyy
>
> WebSharper™ - type-safe JavaScript in F#
> http://intellifactory.com
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
--
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20130622/8d3c3906/attachment.htm>
More information about the Haskell-Cafe
mailing list