Client or Server centricity & GUI automation

asked 2008-03-06 20:17:07 +0800

admin
18691 ● 1 ● 10 ● 130

Orignial message at:
https://sourceforge.net/forum/message.php?msg_id=4820848

By: b_mcdonald

One of the things that ZK does that's different from all the other Web2.0 frameworks (Prototype, jQuery, YUI, etc) is that it puts the behavior code (control and
model) back on the server: "In response to these challenges, ZK delivers the intuitive desktop programming model to Web applications with event-driven, component-based, and server-centric architecture" "It is aimed to bring the desktop programming model to Web applications."

It seems that the web client/server paradigm has forced traditional event driven GUI design to become page centric instead of event centric. I mean, 'how did we go from a "good" GUI design model in desktop applications to such a disjointed and disconnected GUI design model (ie Web pages) that makes GUI development more combersome?' If doing GUI design the way we do today for the web were a better way to do GUIs, wouldn't we have been doing this on the desktop before, or at least since? I feel like the web gui technology is making me do more work, not helping me do less; I'm serving the technology, not the other way around. It seems that all the technical reasons (wanting dynamic behavior on a web user's browser, needing good response times, not wanting actual programs like applets on the client, security, etc and of course the fact that there are 2 computers separated by a network) forced us to abandon the traditional event driven GUI programming model. But now that the client has some entrenched and established built-in or plug-in platforms like javascript, xhtml, dom support, etc, a web application shouldn't be designed to run on either one in particular because of the client/server split... Although developers (or frameworks/tools) decide what should be on which platform, this is a conscience static decision.
What if it was more dynamic?

I would like to see automation of GUI balancing. Think of load balancing but for the application's GUI between client and server. For example, just like you shouldn't care which http server you hit as long as it 'works' the way you expect it to (response time, content, behavior, security, etc), you shouldn't care if the code is on the server or the client as long as it 'works' the way you expect it to (response time, content, behavior, security, etc). Most of these decisions should be managed by automation. A GUI balancing manager would figure out where (client or server) things would be located to meet the goals of the application. For example, it would decide that simple validation should be done on the client, or intensive interactive 3D rendering should be done on the client, while lazy loading of data may be done by calling back to the server when the data is requested by a gui event. In other words, it takes care of resource management for the application between the 2 resources (client and server). It could use heuristics to make it smarter, and to help it learn based upon the user's usage as well as server resource consumption.

Some of the heuristics would be simple and therefor static like "text validation is done on the client" or "password validation is done on the server", but you could do this from the perspective of policy, and not have to hard code it into your design. Some might be more dynamic, like always populating a rock&roll playlist on the client when the internet radio page downloads because the user almost always clicks on it (cookies) vs. NOT populating the 'new age' list because they've never clicked on it.

Your thoughts?