[Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[Alberto G. Corona]

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 :

> 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 
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
>>>
>>> T

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[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?

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

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[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?
>
> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona 
> 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 :
> >
> >> 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 <
> agocor...@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 wi

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[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
"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 

> 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?
>>
>> On Tue, Sep 18, 2012 at 12:33 PM, Alberto G. Corona 
>> 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 :
>> >
>> >> 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 <
>> agocor...@gmail.com>
>> >>> wrote:
>>  Hi haskellers and specially the web developers.
>> 
>>

Re: [Haskell-cafe] Fwd: [Haskell] ANNOUNCE: MFlow-0.1.5

[Alberto G. Corona]

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