Will show how long running tasks, Web apps, workflows, EAI Orchestration and BPM applications share the same underlying problem: The "integration problem", that only haskell can solve with more simplicity, generality and maintainability
Creating a single application in the imperative style is easy and intuitive, because the programmer is in control of the sequence of things to do. But when it comes the time to integrate two or more autonomous entities that send events at any time in its own sequence then is when the programmer is not in control, so a different programming model is necessary. Such problem happens when trying to integrate the users with backoffice applications via web applications, but also when it is necessary to integrate two or more backoffice applications, company departments, web sites, web services etc.
The standard model that solves this inversion of control problem has various names but esenstially is the same architecture with different names: finite state machine, state-transition system, a state machine system or a event handling model. That is the architecture of the main web frameworks, Enterprise Application Integration (EAI) frameworks, Orchestration frameworks, Workflow frameworks, Service Oriented Architecture (SOA) frameworks and Business Process Management (BPM) frameworks, that solve respectively, the individual above mentioned integration problems.
See the tutorial at
https://www.fpcomplete.com/user/agocorona/how-haskell-can-solve-the-integration-problem
With a practical example.
Sunday, December 22, 2013
Friday, November 15, 2013
10+ things that you can do with MFlow and you can't with your Web framework
- Create test, integrate and install your logic without concern for layout. Edit your forms, widgets, style and content at run time.
- Convert your application from single page to multiple page and back with little code modifications
- Make forms that change their questions depending on your answers.
- Make a cascade menu with dynamic options programmatically in a single procedure
- Make an element of a page to refresh itself by adding a single statement
- Make an element to push its content with a simple modifier
- Press back as many times as you like by default
- Write a payment flow with some pages and seamlessly drop it whenever you need it
- Write an active page element with his own server code, JS, CSS in a single procedure and seamlessly drop it whenever you need it
- Write your routes and control logic as in a console application. No spaguetty callback code
- Transparently store and retrieve session data for as long as you wish
- Make all of this without writing a single line of javaScript code. Although you can add it.
- Make all of this in a type safe way. If your app compiles, it works.
- Make (almost) all of this work with or without javascript activated.
- Make all of this in an architecture that is horizontally scalable (although not implemented such scalabiltiy yet)
Quick Start : Basics for understanding and using MFlow
Quick Start 2 : how to modify an application to add dynamic effects: implicit ajax, push etc.
MFlow site: http://mflowdemo.herokuapp.com
Monday, November 11, 2013
Learning from the Haskell compiler
Haskell programming is naturally one level of abstraction above other languages either functional or not. It is not the functional paradigm. It is the type inference and, specially, the category theoretical grounds in which the language is based, for which functional and imperative paradigms are particular cases.
The extra level of abstraction means that you are one level up in the tree of possibilities. For example, you can define the very meaning of a sequence of statements in a Monad Instance. That, in other languages is fixed.
That means that you have a extra level of things to learn and explore. For example I created a DSL for web applications time ago and still I´m learning my own language. Sometimes my programs type check, but they do not perform what I was expecting, But it does other interesting thing. The code was a product of my own misunderstanding or my lack of concentration, but the type checker say: its valid, let´s run it. Then I check it again and voila, when I examine the program I discover a new usage of the same elements I defined that I never though previously possible.
Sometimes the error messages tell me new instances of things that I would never though about. Some of them seem crazy, but after a second though, I find that is not as crazy as it seems but, sometimes I´m not willing to accept yet another extra level of abstraction that my compiler is suggesting as result of an error.
For beginners this flood of information is confusing,as well as for expert programmers they just want their job done, but thanks in part to this interaction I´m here talking about abstract web combinators when what I initially needed from Haskell was the fsstest way to see "hello world" in a web browser.
Saturday, November 02, 2013
More composable elements for single page development: witerate and dField
witerate, is a new primitive that permits to iterate the presentation of data and/or input fields and widgets within an web page that does not change. The placeholders are created with dField. Both are widget modifiers: The latter gets a widget and create a placeholder in the page that is updated via ajax. The content of the update is the rendering of the widget at each iteration. The former gets a widget which contains dField elements and permit the iteration. Whenever a link or a form within the witerate widget is activated, the result is the placeholders filled with the new html content. This content can be data, a input field, a link or a widget. No navigation happens.
This permits even faster updates than autoRefresh. since the latter refresh the whole widget and it does not permits modifications of the layout at runtime. When edTemplate or template is used on top of witerate, the result is editable at runtime, and the span placeholders generated, that are updated via ajax can be relocated within the layout of the template.
Additionally, contrary to some javascript frameworks, the pages generated with this mechanism are searchable by web crawlers.
This example below, taken from the runtime templates example, shows how template, witerate and dField work together. The example iterates the presentation of a list of results fby displaying four of them each time. The list can be navigated forward and backward. (see the example running and the full source code here).
These are two pages of the example with the templates beind edited at runtime. The first present results and the second is an input form managed the same way. Since the pages are not refreshed, this permits very fast input and presentation of results.
The full post explaining everything is here:
http://mflowdemo.herokuapp.com/noscript/wiki/singlepage.html
This permits even faster updates than autoRefresh. since the latter refresh the whole widget and it does not permits modifications of the layout at runtime. When edTemplate or template is used on top of witerate, the result is editable at runtime, and the span placeholders generated, that are updated via ajax can be relocated within the layout of the template.
Additionally, contrary to some javascript frameworks, the pages generated with this mechanism are searchable by web crawlers.
This example below, taken from the runtime templates example, shows how template, witerate and dField work together. The example iterates the presentation of a list of results fby displaying four of them each time. The list can be navigated forward and backward. (see the example running and the full source code here).
These are two pages of the example with the templates beind edited at runtime. The first present results and the second is an input form managed the same way. Since the pages are not refreshed, this permits very fast input and presentation of results.
The full post explaining everything is here:
http://mflowdemo.herokuapp.com/noscript/wiki/singlepage.html
See the page and the full source code here
Thursday, October 31, 2013
About client-side frameworks
Before any consideration about either client-side or server side framworks are good for one or other user case, you, as a programmer has to answer a simple question: is the Web browser a good development, integration, test and exploitation platform? My response is: No.
I love JavaScript. I programmed AJAX applications using hidden frames 13 ago, before this technology had a name. I regularly used client side technologies for editing documents, for example, Google Docs. But what makes great Google docs is the server integration of many client and server side developments.
You finally must integrate different aspects of your applications: user data, different client-side applications , snippets to compose workflows and you have to decide where you integrate all of this. Either you integrate it in the server of in the client. if you do it in the client, you hardly will do multi-user stuff. you will not have a type safe, fast, multi-threaded environment under your control. You are restricted to the single threaded, single user javaScript environment. if you use some framework above that you still are restricted to the limitations of the JavaScript virtual machine and development environment.
There are lots of client side frameworks that promise a declarative extension of HTML, but if you look at AngularJS, you will see a lot of JavaScript code, with all the big complexities of big server side frameworks, but, looking at the examples, these frameworks are devoted to present server data, in which they add little additional advantages, except perhaps less server-client traffic. A server side framework can do it as well with adequate use of AJAX, (see this)
To summarize you have the problems of two tier architectures, the thick client problem aggravated with less power of the sandboxed environment of the web browser. Until you load all the client framework, the first page display can experiment delays. Although this could not be a problem in intranet environment where two tiered architectures have been good for a limited number of users, that is specially critical in applications with a casual usage pattern, such are all Web applications. The dynamic HTML is not searchable. You must see how Twitter had to revert to the server side.
You may think that a server with application logic and a MVC event driven logic in the middle tier, can solve the problem, but, simple speaking, the business applications are not stateless. Neither you can store the state in the client allways. Have you seen a flowchart?, a user requirement document? all of them are filled with steps. Specially in a corporate environment, where it is necessary to integrate different software elements, departments, databases etc, much of the integration of different modules with the corresponding interfaces must be trough an stateful application that present different interfaces.
And the development process in which each one works at the highest level of productivity and abstraction is when you can package server and javascript functionalities that work together in easily pluggable, self contained widgets for the user interface. With these widgets, let the application programmer to compose single-page applications and finally with these single-page applications, integrate them in stateful workflows that accomplish the whole user case. That is the aim of MFlow.
Thursday, October 17, 2013
Change the content & layout of an active page with WYSIWYG at runtime?
It is possible modify the layout of the active components at run-time. This means that no longer is necessary to code a layout for a formulary, or for the arrangement of different widgets.
Just create them without layout, and later the people in charge of the layout and styles will arrange the layout and the texts when the application is already tested. Then the layout never pollutes the code, and it may be decoupled also in time.
The layout can be edited in a more powerful editor and inserted again and so on. As long as the designer do not modify the tags of forms and links created by the application, everithing goes fine. It can insert wathever content, formatting, apply styles etc.
The validation errors in the formularies must be presented via Javascript however. The example uses a simple javascript alert to present an error when the message entered in the form field exceed a certain length
The example list the names entered in a input form, but at the same time it permits the edition of the three pages: The first page has links. There is a page with a form for entering a new name and the content of a list of results.It uses edTemplate and edTemplateList, two new primitives for template edition.
Log in as edituser/edituser to edit the pages using the login option. Log out to see the resulting layout. The edited layour has additional information about how it works.
A cascade menu coded in pure applicative & monadic haskell?
Now the mflow demo has a cascade menu.
It uses the behaviour of the monad instance of the MFlow formlets. But in this case it uses links instead of forms elements.
Here is the code of two branches of the cascade menu:
absLink ref = wcached (show ref) 0 . wlink ref
mainMenu ∷ View Html IO Options
mainMenu= autoRefresh $
ul <<< li <<< do
absLink DatabaseSamples << b "Database examples"
<++ " with different backends"
ul <<<
(li <<< (absLink MFlowPersist << b "Persistent") <! noAutoRefresh
<++ do -- blaze-html monad
b " illustrates the use of MFlow with "
a "Persistent" ! href yesodweb
" (In this example sqlite backend is used) "
article persistentarticle
<|> li <<< (absLink Database << b "Database") <! noAutoRefresh
<++ b " Create, Store and retrieve lines of text from Amazon SimpleDB \
λ storage "
<> article amazonarticle)
<|> li <<< do
absLink PushSamples << b "Push Samples"
<++ " using long polling"
ul <<<
(li <<< (absLink Push << b "Push example") <! noAutoRefresh
<++ b " A push widget in append mode receives input from \
λa text box with autorefresh"
<> article pushl
<|> li <<< (absLink PushDec << b "A push counter") <! noAutoRefresh
<++ b " Show a countdown. Then goes to the main menu"
<> article pushdec)
<|> li <<< do
......
It works as follows:
The menu is a set of links composed by applicative alternative (<|>) operators. each operator contains a do sequence so according with the monad instance, the sequence executes as long as the previous lines of the sequence are validated by the user input, so when the first link in the do sequence is clicked, the next sentence can be executed. So when the top level link is clicked, what appears is a second level of links composed again with the (<|>) operator. They are the terminal branches in this case. (the process can go down further with a new level, if it is necessary). The final branches are absolute links with the class= _noAutoRefresh attribute. This tell autoRefresh to escape from local auto-refreshing and permit a page navigation when this link is pressed.
autoRefresh install the javascript and server flags necessary for auto-refreshing the menu without refreshing the whole page.
The operator (<<<) encloses the HTML of a widget within anoter HTML tag. In this case the tags UL and LI encloses the links.
absLink is a cached wlink and thus has a fixed path. this absolute link is convenient since the code backtrack when a menu item is cliked from any option (see this article).
(<++) append HTML code to a widget.
The behaviour can be improved, for example,if instead of collapsing each branch when a new branch is open, to maintain any number of branches open, just add its own autoRefresh for each branch instead of a general autoRefresh.
One additional NOTE about this code: There is a round-trip to the server each time an option is pressed, but for once, this permits the presentation of mutable data which is arranged in three-like structures, not only static menus. In the other side, the server code that respond the requests is ready waiting and with all the context in place, no lookups, typical of MVC frameworks are necessary, so the response has a very short latency, about 5 ms latency in the server, according with my heroku box. Here are the typical response parameters for the menu refresh:
connect=1ms service=5ms status=200 bytes=2862
- Database examples with different backends
- Persistent illustrates the use of MFlow with Persistent(In this example sqlite backend is used) (article)
- Database Create, Store and retrieve lines of text from Amazon SimpleDB storage (article)
- Push Samples using long polling
- Error Traces
- Different kinds of flows
- Basic Widgets
- Monadic widgets, actions and callbacks autoRefresh, page flows, dialogs etc
- Dynamic Widgets Widgets with Ajax and containers of other widgets
- Runtime templates Templates and content management modifiable at runtime
- Login/logout
It uses the behaviour of the monad instance of the MFlow formlets. But in this case it uses links instead of forms elements.
Here is the code of two branches of the cascade menu:
absLink ref = wcached (show ref) 0 . wlink ref
mainMenu ∷ View Html IO Options
mainMenu= autoRefresh $
ul <<< li <<< do
absLink DatabaseSamples << b "Database examples"
<++ " with different backends"
ul <<<
(li <<< (absLink MFlowPersist << b "Persistent") <! noAutoRefresh
<++ do -- blaze-html monad
b " illustrates the use of MFlow with "
a "Persistent" ! href yesodweb
" (In this example sqlite backend is used) "
article persistentarticle
<|> li <<< (absLink Database << b "Database") <! noAutoRefresh
<++ b " Create, Store and retrieve lines of text from Amazon SimpleDB \
λ storage "
<> article amazonarticle)
<|> li <<< do
absLink PushSamples << b "Push Samples"
<++ " using long polling"
ul <<<
(li <<< (absLink Push << b "Push example") <! noAutoRefresh
<++ b " A push widget in append mode receives input from \
λa text box with autorefresh"
<> article pushl
<|> li <<< (absLink PushDec << b "A push counter") <! noAutoRefresh
<++ b " Show a countdown. Then goes to the main menu"
<> article pushdec)
<|> li <<< do
......
It works as follows:
The menu is a set of links composed by applicative alternative (<|>) operators. each operator contains a do sequence so according with the monad instance, the sequence executes as long as the previous lines of the sequence are validated by the user input, so when the first link in the do sequence is clicked, the next sentence can be executed. So when the top level link is clicked, what appears is a second level of links composed again with the (<|>) operator. They are the terminal branches in this case. (the process can go down further with a new level, if it is necessary). The final branches are absolute links with the class= _noAutoRefresh attribute. This tell autoRefresh to escape from local auto-refreshing and permit a page navigation when this link is pressed.
autoRefresh install the javascript and server flags necessary for auto-refreshing the menu without refreshing the whole page.
The operator (<<<) encloses the HTML of a widget within anoter HTML tag. In this case the tags UL and LI encloses the links.
absLink is a cached wlink and thus has a fixed path. this absolute link is convenient since the code backtrack when a menu item is cliked from any option (see this article).
(<++) append HTML code to a widget.
The behaviour can be improved, for example,if instead of collapsing each branch when a new branch is open, to maintain any number of branches open, just add its own autoRefresh for each branch instead of a general autoRefresh.
One additional NOTE about this code: There is a round-trip to the server each time an option is pressed, but for once, this permits the presentation of mutable data which is arranged in three-like structures, not only static menus. In the other side, the server code that respond the requests is ready waiting and with all the context in place, no lookups, typical of MVC frameworks are necessary, so the response has a very short latency, about 5 ms latency in the server, according with my heroku box. Here are the typical response parameters for the menu refresh:
connect=1ms service=5ms status=200 bytes=2862
Subscribe to:
Posts (Atom)