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.

The question is not either client or server side. Both parts must believe that they are the center of the development. the user too. When you are programming in the client, you must think client centric. when you are in the server, you have to feel server centric. The intelligent way is  make everyone: The user, the front-end programmer, the back-end programmer, the integrator, to feel that they are the center of the development.

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.

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

http://mflowdemo.herokuapp.com/noscript/templates/runtimetemplates

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.

• 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

The menu works as any cascade menu, but it does not use explicit javascript to display and hide the branches when clicked. It uses pure haskell with applicative and monadic combinators.

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

What I have been doing: Runtime templates and Content Management

Hi,

There are two exciting things that I´m being doing lately: Content management has been improved a lot. Now the editors can edit large texts at runtime and see the result instantly. They have an edition panel with all the ordinary functionalities including uploading and linking images, edition of raw HTML and so on. Different users can have permissions for different sections. See the content of the home page of the MFlow demos. It has been created with this content management facility at runtime. The content management demo shows how it works.

After you have logged with the right user, to edit the text click on them. immediately, the panel above is activated and the content can be edited. At the end, clicking the save button, the edition facility and the panel disappear and the editor see the exact layout of the page. To edit it again, just refresh the page. The content is published immediately. for the public. The content is saved in the texts folder.

Very related with this, but more exciting and powerful, is the possibility to modify the layout of the active components at run-time. This means that no longer is necessary to define a layout before compilation for a formulary,  or for the arrangement of different widgets. Just create them without layout, and later the stylist 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. he 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.

This does not end here. There may be more than one layout,with more or less text, advertising etc depending o the device. For example,  a slim layout for mobile phones, other more heavy for PCs etc. This is something that I´m just developing now. T