Update: I did a newer implementation here

In an attempt to trace the program flow of our Javascript client application we needed a stack trace of function calls. We needed to eliminate unneeded redraw and keep the code flow intact.
Over at deep some amazing AOP stuff in Javascript can be found. So what we did to print the stack trace? only an advice is added before all the interrested functions (Javascript has enough reflective abilities for us to be able to inject these advices along our object graph dynamically). And now we have a nice and accurate call stack! Ofcourse many cases of redraw are gone now. And we introduced another feature into our Javascript beast, AOP capabilities!

Any self respecting MVC framework would have some sort of view manipulation. Almost all those sever centric frameworks have some sort of view manipulation. You create your views in your templating engine of choice (Velocity, Smarty, ERB, ASP, JSP or whatever). The views are processed by the server and the rendered result is sent to the browser. Some templating and view technologies go an extra step further an enable you to use cached copies of the compiled view templates.

Of particular interest where the SpringMVC and the RubyOnRails frameworks. Both provide means for view handling. And both provide hooks for custom view handlers. Which would lead to the interesting question.

What's wrong with the current view handlers?

All these handlers operate in the classical web application linked pages model (Web 1.0). With the eager move to Single Page Applications (Web 2.0) we need to add these abilities to current frameworks (or create new frameworks?)

How can we acheive this?

Instead of sending complete pages. The server should send to the client data only. And this data should only be view data with no control data. The view control data should reside completely on the client. So instead of responding to a list_items request with a rendered html page with the items required we will only send the data required. To be parsed and rendered by the client browser.

And data format?

Although it seems natural that we use XML for data sending. In a web browser environmnet it is more fit to use a more Javascript friendly approach. JSON (which is very XML like but in native Javascript) can be used as a data interchange medium. JSON will easily be parsed into live Javascript objects. Passed easily to templates (Javascript Templates from trimpath). And used to store model cache if needed (keeping the cache in the native Javascript format rather than XML is crucial for performance).

Template Engine?

As mentioned above. The Javascript Template from www.trimpath.com act as a very good alternative to its server side cousins. It has Smarty, Velocity like syntax. And it is very extinsible. The only draw back is that it is lacking an include mechanism (though this is partially solved by using its Macros)

And the result?

Adding web 2.0 application capabilities to the current tried and true web application frameworks. Making it easy to move even current apps to the user friendly era of web 2.0. I will be working soon in the Spring to JStemplates interfaces and I might delve into a RoR implementation as well (this would be very easy I believe, might envolve overriding a method or two in the action controller). The only thing that is missing is standardizing the client side controller code.

I just saw Amr Khaled on TV a moment ago. It's been a while since the last episode of his program (life makers) was aired. I really missed the man! He has a way in speaking that manages to capture me every time. Specially at this time before Ramadan. The program was being aired from Egypt which means that Amr actually manages to visit his own country from time to time. My participation in his life makers program was far beyond what I would like to do. I will try to
be more active in the coming months. And I will try to make this Ramadan the best so far. Amr is the kind of man that is able to rally people for a good cause. He is our Gandhi! And more!. I just wish we all give him all the support we can. May Allah reward us all. Amen

Over at theserverside.com Alexander Jerusalem wrote: Does JSF + AJAX really make sense? He raised some serious questions about how should the client and server interact and how could we maintain the server state when the client updates the form elements dynamically.

His worries are very well founded and stem from the fact that current web application frameworks are mostly server centric. The server is playing a monoply on the data model, action control and even view state.

Here's a look from the other side of the fence. I was not doing much Java development as of late and instead of using bell-and-whistle based frameworks I was participating in a big project that had the following properties:

• Huge client base that consumed the processing power and the bandwitdh of the server(s)
• Distributed implementation which should be done as simple as possible due to time constraints
• Distributed data set (per user data are private and thus caching has no real system wide effect)
• To stress the first point. Processing and bandwidth were at premium! we had to save on both.
  

Now the server centric frameworks that are all around us are far from suitable for such a beast. In fact it does not have to be a beast at all! We followed the KISS model and made ourselves a winner!

Recipe for success:

• Build a stateless server application (only loggedIn? should be tracked)
• The server only responds to fine grained actions (for some actions the server responded with JSON data, for most of the action the server simply said: "ok")
  
• Put this app on as many servers as you wish as long as they share the data and can share the loggedIn? peice of info.
• Build a statefull SPA client:
• Full model and model cache (use the cache to avoid visiting the server often)
  
• Full fledged controller (the client decides what happens next)
  
• Complete View rendering and management (Javascript templates any one?)
• Connect everything using Ajax and JSON (how thinner can we get?)
• Forget about HTMLUnit (use your own Javascript infrastructure to test and direct your DOM)

What was good about such an application?

• Fast prototyping
  We managed to get a prototype (no server side thing) up and running in no time. Even during development the evolving prototype would be one step ahead by relying on static data rather than server responses
• Prototype reuse
  The prototype actually became the application! It was continously under refactoring but the team managed to always keep it under control
• Real Distributed Application
  The clients now do the controlling part and the parsing and rendering of view templates. They keep the view state and the model state (through the cache) only updates are propagated to the server. Much less processing on the server(s) now
• Bandwidth Savings
  Down to 25% of the original bandwidth consumption (more savings expected) and due to decreased server load we are now able to use mod_deflate for even better savings
  

So did we find ourselves a killer framework for next generation web apps? I doubt! but I believe that we have now the optimum solution for our type of problem. Some other problems might need different solutions and might not benefit from such an approach. But to see Alexander's words in another view: Yes sometimes Ajax and JSF dont co-exist. Sometimes you'll need to drop JSF for Ajax to work the way you want!

Most Ajax guides available online would tell you how Ajax is our way to the asynchronus client programming. Follow that with an example of how to build Ajax requests with details upto callback management. The poor reader will grab the code and paste it in his/her application and will find it working. After his/her application grows things will start to miss behave. What went wrong? The poor fellow who had little to no knowledge of Javascript (and may be shunned it off earlier as a languange for those who can't do real programming) didnt give the script a good look trying to figure out what's going on first.

Here's an example from developer.apple.com :

var req;

function loadXMLDoc(url) {
 req = false;
// branch for native XMLHttpRequest object
if(window.XMLHttpRequest) {
 try {
   req = new XMLHttpRequest();
    } catch(e) {
   req = false;
    }
// branch for IE/Windows ActiveX version
} else if(window.ActiveXObject) {
    try {
     req = new ActiveXObject("Msxml2.XMLHTTP");
   } catch(e) {
     try {
        req = new ActiveXObject("Microsoft.XMLHTTP");
     } catch(e) {
        req = false;
     }
  }
}
 if(req) {
  req.onreadystatechange = processReqChange;
  req.open("GET", url, true);
  req.send("");
 }
}

function processReqChange() {
 // only if req shows "loaded"
 if (req.readyState == 4) {
     // only if "OK"
     if (req.status == 200) {
         // ...processing statements go here...
     } else {
         alert("There was a problem retrieving the XML data:\n" +
             req.statusText);
     }
 }
}

What's the problem with the above code? specially in an asynchronus environment?

The variable req (which is used as the XMLHTTPRequest object) is defined globally!! So when our friend tries to instantiate a new request before the current one finishes it will overwrite it and you will lose any reference to the old request.

But why did we have a global variable in the first place? If it's so bad, why didnt we make it local tothe loadXMLDoc funciton?

Simple, because the call back function needs to access this variable. And if it cannot be found in its scope it will look at it in the global scope.

Closures any one?

this can easily be solved by defining the call back function as an inner function to the loadXMLDoc() function and declaring the variable req as local to this function

function loadXMLDoc(url) {
var req = false;
// branch for native XMLHttpRequest object
if(window.XMLHttpRequest) {
 try {
   req = new XMLHttpRequest();
    } catch(e) {
   req = false;
    }
// branch for IE/Windows ActiveX version
} else if(window.ActiveXObject) {
    try {
     req = new ActiveXObject("Msxml2.XMLHTTP");
   } catch(e) {
     try {
        req = new ActiveXObject("Microsoft.XMLHTTP");
     } catch(e) {
        req = false;
     }
  }
}
 if(req) {
  req.onreadystatechange = processReqChange;
  req.open("GET", url, true);
  req.send("");
 }

 
var processReqChange = function() {
    // only if req shows "loaded"
  if (req.readyState == 4) {
        // only if "OK"
         if (req.status == 200) {
          // ...processing statements go here...
         } else {
            alert("There was a problem...");
   }
    }
 } 
}

All we needed to do is declare req as a local variable by adding the var keyword and removing the global declaration.

This way each request will spawn a new req object which will be accessed by the callback function and will be garbage collected after the callback function returns (some browsers - namely older versions of internet explorer - might leak memory here as they deal very badly with closures)

Great news for all the national party members. Mubarak won the elections with a staggering 88.5%!.
The Egyptians voiced their opinion! and what I conclude for it is :

1. They dont care for the 19000 wrongfully imprisoned fellow Egyptians
2. They dont care for being poisoned with illegal pesticides
3. They dont care if their childern recieve no education at all
   

which calls for an interesting question, what do the Egyptians care for?