[Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5
Alberto G. Corona
agocorona at gmail.com
Tue Sep 25 13:08:19 CEST 2012
Hi,
This is an difficult problem in which the design principles of MFlow can
help to creare a solution amazingly easily.
I forward this message from, Web-devel because I think that it may be of
interest
A Web app. that creates Haskel computations from form responses. Store
them, retrieve and execute them
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" 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
> case (mop,back) of
> (Just goop,False) -> goop
> _ -> do
> r <- 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/haskell-cafe/attachments/20120925/7a46bbbc/attachment.htm>
More information about the Haskell-Cafe
mailing list