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

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 "goingBackhttp://hackage.haskell.org/packages/archive/MFlow/0.1.5.3/doc/html/MFlow-For..." 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-For... 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-For... option1 <|> option2 case r of op1 -> setGoStraighTo (Just goop1) >> goop1 op2 -> setGoStraighTo (Just goop2) >> goop2

2012/9/18 Alberto G. Corona

...

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

...

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?

...

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

On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona wrote: 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 :

...

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 :

...

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@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-For... > > 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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Alberto.