[web-devel] [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5
Alberto G. Corona
agocorona at gmail.com
Mon Sep 24 12:20:56 CEST 2012
Hi,
This is an difficult problem in which the design principles of MFlow can
help to creare a solution amazingly easily.
http://haskell-web.blogspot.com.es/2012/09/a.html
Alberto
2012/9/18 Alberto G. Corona <agocorona at gmail.com>
> However if in a tab out of sync the user press refresh, the tab will
> refresh to the current state.
> I took care not to try to synchronize back as a consequence of a page that
> is in a forward state in one tab, as a consequence of navigating back in
> other tab. However I may have not considered all the edge extreme cases.
>
> There is a back detection primitive "goingBack<http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Forms.html#v:goingBack>"
> that allow the programmer to control the back behaviour in some special
> cases.
>
> For example if i want to step over a menu and present a default page, But
> if when the user go back i want to present the menu, I can detect this
> condition and present this menu, that did not appeared in a normal
> navigation:
>
> This code sets and get a default option in the menu, so the menu is not
> shown again in the navigation, except in the case that the user press the
> back button. Otherwise, the menu would be never accessible.
>
> However this is very specialized. normally the back button detection is
> not necessary. In a persistent flow even this default entry option would be
> completely automatic, since the process would restar at the last page
> visited. No setting is necessary.
>
>
> menu= do
> mop <- getGoStraighTo
> back <- goingBack <http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Forms.html#v:goingBack>
> case (mop,back) of
> (Just goop,False) -> goop
> _ -> do
> r <- ask <http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Forms.html#v:ask> option1 <|> option2
> case r of
> op1 -> setGoStraighTo (Just goop1) >> goop1
> op2 -> setGoStraighTo (Just goop2) >> goop2
>
>
>
>
>
> 2012/9/18 Alberto G. Corona <agocorona at gmail.com>
>
>> Hi Jake,
>> right, it depends on the identification of the session:
>>
>> iAll the tabs share the same state because they share the same cookies.
>> so if in one tab the use continue the interaction then the other tabs are
>> out of sync. If the user goes to these other tabs and press any widget, the
>> application will synchronize back to this page.
>>
>>
>> This happens also if the user is logged in different computers.
>>
>> Alberto.
>>
>> 2012/9/18 Jake McArthur <jake.mcarthur at gmail.com>
>>
>>> Actually, I meant users that spawn multiple tabs from a single root
>>> session. You mentioned that you have some special support for the back
>>> button. What happens if I open a couple new tabs in which I may or may
>>> not go forward and backward. Do they all share the same state?
>>> Different states (how?)? Partially shared states?
>>>
>>> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona <agocorona at gmail.com>
>>> wrote:
>>> > Oh, I´m stupid. You mean web pages with multiple tabs....
>>> >
>>> > I have not tested it. but each tab can be handled easily by a
>>> different
>>> > server process.. or it can be handled in a single server process, like
>>> in a
>>> > menu. For example, this code present different options, and the process
>>> > renders different things depending on the response.
>>> >
>>> > The last option is a link to a different process, while the others(
>>> wlinks)
>>> > are links that return back to the same process.
>>> > The operator <|> is the applicative operator. a breakline is
>>> prepended to
>>> > each link:
>>> >
>>> > data Ops= Ints | Strings | Actions | Ajax | Opt deriving(Typeable,Read,
>>> > Show)
>>> >
>>> > mainf= do
>>> > r <- ask $ wlink Ints (bold << "increase an Int")
>>> > <|> br ++> wlink Strings (bold << "increase a String")
>>> > <|> br ++> wlink Actions (bold << "Example of a string
>>> > widget with an action")
>>> > <|> br ++> wlink Ajax (bold << "Simple AJAX example")
>>> > <|> br ++> wlink Opt (bold << "select options")
>>> > <++ (br +++ linkShop) -- this is an ordinary XHtml link
>>> >
>>> > case r of
>>> > Ints -> clickn 0
>>> > Strings -> clicks "1"
>>> > Actions -> actions 1
>>> > Ajax -> ajaxsample
>>> > Opt -> options
>>> > mainf
>>> > where
>>> > linkShop= toHtml $ hotlink "shop" << "shopping"
>>> >
>>> > .
>>> > Alberto
>>> >
>>> > 2012/9/18 Alberto G. Corona <agocorona at gmail.com>:
>>> >
>>> >> Hi Jake
>>> >>
>>> >> I don´t know what you mean with multiple tabs. The user management is
>>> >> simple, anonymous clients are identified with a cookie. if the user
>>> >> is logged (MFlow has widgets for logging-validation) the user is the
>>> >> identifier.
>>> >>
>>> >> The state of a process is associated to the client identifier and to
>>> >> the path invoked in the url requested.
>>> >>
>>> >> I don´t know if this answer your question....
>>> >>
>>> >> Alberto
>>> >>
>>> >> 2012/9/18 Jake McArthur <jake.mcarthur at gmail.com>:
>>> >>> This sounds really cool.
>>> >>>
>>> >>> How do you handle users having multiple tabs?
>>> >>>
>>> >>> On Tue, Sep 18, 2012 at 11:26 AM, Alberto G. Corona <
>>> agocorona at gmail.com>
>>> >>> wrote:
>>> >>>> Hi haskellers and specially the web developers.
>>> >>>>
>>> >>>> http://hackage.haskell.org/package/MFlow-0.1.5.3
>>> >>>>
>>> >>>> MFlow is a is a Web framework with some unique, and I mean unique,
>>> >>>> characteristics that I find exciting:
>>> >>>>
>>> >>>> - It is a Web application server that start and restart on-demand
>>> >>>> stateful web server processes (not request.-response)
>>> >>>> This means that all the page navigation can be coded in a single
>>> >>>> procedure. This increases readability of the programmer code. I woul
>>> >>>> call it
>>> >>>> a anti-node.js. Buit usual request-response (stateless) server
>>> >>>> processes are also allowed
>>> >>>>
>>> >>>> - When the process is invoqued as result of an URL request, the Web
>>> >>>> app server not only restart the process but also recover its
>>> execution
>>> >>>> state. The enclosing Workflow monad provides the thread state
>>> >>>> persistence. There are state timeouts and process timeouts defined
>>> by
>>> >>>> the programmer. Processes with no persistent state (transient) are
>>> >>>> possible.
>>> >>>>
>>> >>>> -The user interface is made of widgets. They are formlets with
>>> added
>>> >>>> formatting, attributes, validations, modifiers and callbacks, that
>>> >>>> are composable, so the pieces are reusable and return type safe
>>> >>>> responses to the calling process. Even the links are part of widgets
>>> >>>> and return back type safe inputs at compile time to the calling
>>> server
>>> >>>> process. Tho glue these components, ordinary applicative combinators
>>> >>>> and other extra combinators are used.
>>> >>>>
>>> >>>> - The widgets and the communication don´t make assumptions about the
>>> >>>> architecture, so it can be adapted to non-web environments. This
>>> >>>> versions has interface for WAI-warp, Hack, Text.XHtml (xhtml) , and
>>> >>>> Haskell Server Pages.
>>> >>>>
>>> >>>> -The widget rendering can be converted to ByteStrings automatically
>>> >>>> with special combinators. A mix of widgets with different formats
>>> can
>>> >>>> be combined in the same source file. For example Text.Html and HSP
>>> >>>> (Haskell server pages)
>>> >>>>
>>> >>>> -These widgets can be cached, to avoid widget rendering on every
>>> >>>> interaction.
>>> >>>>
>>> >>>> -To handle the back button, and because the processes are stateful,
>>> >>>> they can run backwards until the response match. This is transparent
>>> >>>> for the programmer, thanks to the embedded FlowM monad.
>>> >>>>
>>> >>>> -All the code is in pure Haskell. No deployment, special scripts,
>>> >>>> formats etc are necessary.
>>> >>>>
>>> >>>> -Besides automatic state persistence, TCache provides transactions
>>> and
>>> >>>> user data persistence, that can be configured for SQL databases.
>>> >>>> Default persistence in files permit very rapid prototyping. Just
>>> code
>>> >>>> and run it with runghc.
>>> >>>>
>>> >>>> -Has AJAX support
>>> >>>>
>>> >>>> All of this sounds very complicated, but really it is simple!. Most
>>> of
>>> >>>> these things are transparent. The resulting code is quite readable
>>> and
>>> >>>> has very little plumbing!
>>> >>>>
>>> >>>> There is a non trivial example that some of these functionalities
>>> >>>> embedded here that you can run:
>>> >>>>
>>> >>>>
>>> >>>>
>>> http://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-Forms.html
>>> >>>>
>>> >>>> Take a look and tell me your opinion. I hope that you find it as
>>> >>>> exciting as me.
>>> >>>>
>>> >>>> I´m looking for people to collaborate in the development of MFlow.
>>> >>>>
>>> >>>> Although still it is experimental, it is being used in at least one
>>> >>>> future commercial project. So I have te commitment to continue its
>>> >>>> development. There are many examples in the documentation and in the
>>> >>>> package.
>>> >>>>
>>> >>>> Alberto
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Haskell mailing list
>>> >>>> Haskell at haskell.org
>>> >>>> http://www.haskell.org/mailman/listinfo/haskell
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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/web-devel/attachments/20120924/539c4467/attachment.htm>
More information about the web-devel
mailing list