Web Browser Programming Blurring the Lines of MVC 303
lkcl tips his in-depth article up at Advogato on the difficulties for the MVC programming model that are introduced by Javascript and AJAX, and solutions for them. He writes: "This article outlines how the MVC concept is made incredibly awkward by the gradual but necessary introduction of Javascript and AJAX. A solution is found in the form of Javascript Compiler Technology such as GWT or Pyjamas (PyPy's JS backend or Rb2Js could be used, with some additional work). The article outlines how and why the traditional MVC patterns are fragmented by Javascript and AJAX, advocating that if a site is programmed purely in a high-level language that is then compiled to Javascript for the Web Browser sections, the same high-level source code can be executed either client-side on the browser, or server-side, or even both, depending on the requirements. The implications of this approach are discussed in depth."
RubyJS (Score:4, Informative)
also found, since the submission, rubyjs [rubyforge.org] which is a ruby-to-javascript compiler and yet another port of GWT - this one's called rwt [rubyforge.org]
Security issues. (Score:5, Informative)
Careful when you blur the lines.
The gains might not be as much, because there's a very big difference between running your code on an untrusted client vs running your code on your server.
It may be rather hard to enforce the integrity and security checks at server side when you start to do more and more stuff on the client.
If the server has to counter check each step, then you still get that round trip latency effect. If you do most of the stuff client side that could mean the server has to figure out what are valid _end_ states from tons of possible intermediate states. Sometimes that might not be possible.
It's not a problem for things like google maps, if you modify their client side javascript to behave differently it's not a big issue.
Machines that can run web but not C++ (Score:2, Informative)
Is there ever a point where a web developer will concede that the web is not the Best Platform for Everything in The Universe(tm)? Or is it just that they were never schooled in the old temple and given a proper appreciation of a real language like C++?
There are a lot of computers that are capable of running arbitrary HTML, CSS, JavaScript, and sometimes even ActionScript, yet incapable of running arbitrary C++ without the developer spending beaucoup bucks to obtain the platform owner's certification. These include the Internet terminal in the break room at work, the Internet terminal at the public library, an unmodded game console, an unmodded smartphone, etc.
Re:What's new is old is new again?! (Score:3, Informative)
The problem is that I have yet to see an implementation through a browser that can challenge a native GUI implementation and yes this includes Sales Force, Google Mail, Google Docs and all the rest of them.
that's why i ported pyjamas to the desktop:
http://pyjs.org/ [pyjs.org]
pyjamas-desktop basically rips out all of the javascript, and replaces every single javascript-based function with exact same corresponding functionality that manipulates the DOM model of the underlying technology.
and i chose http://webkit.org/ [webkit.org] as the DOM-manipulating technology.
i _could_ have chosen XUL / Gecko, but it took so damn long to find Hulahop - http://wiki.laptop.org/go/HulaHop [laptop.org] - that i had to go for webkit.
i could have chosen PyKDE / KHTMLPart but it has very subtle bugs that require the entire KDE library to be compiled with c++ RTTI switched on. if it's switched off, the whole thing falls over.
by porting pyjamas to the desktop, it's possible to make the same application run as EITHER a desktop application (and i don't mean "running as javascript under Adobe AIR") OR a web application.
same source code. unmodified.
it's very cool.
Blurred understanding: MVC is recursive, not flat (Score:5, Informative)
For every instance of MVC, the View component itself can be a complete, nested MVC unit or even a collection of MVC units. This is the nature of the MVC design pattern.
For example, take the humble HTML button. It is its own complete MVC machine. It has a Model (button state, color, size, etc) and controller logic that responds to events (render "down" state, "focus" state, etc.). And of course it has a graphical View.
This MVC button machine can delegate events and control to a parent MVC machine, such as an HTML table.
Delegation continues to parent MVCs at ever higher abstraction layers until finally we're at the level of browser-as-complete MVC machine. The next higher layer involves the server back end, and now the browser is the view component of the server/browser abstraction layer.
If the server implements its GUI interface layer as servlets, for example, then the servlet/browser is a complete MVC machine. But this layer still does not contain the core business logic, since for any well-designed (non-trival) server it should be possible to completely replace the GUI layer (such as Struts, etc) with another GUI framework without affecting the core business logic/data. And so the browser/servlet layer becomes the view component of the highest MVC layer, which has the core business logic as the model and controller.
The MVC pattern supports a recursive tree of MVC state machines, typically managed as parent-child relationships. Low level business logic, such as preventing alpha characters from being entered into a SSN text input field, can be implemented directly in the input field widget's MVC machine. High level business logic/data, such as validating and submitting a complex shopping order, takes place on the highest level MVC state machine.
Business logic/data, like any complex computer science problem, can consist of many different levels of abstraction. It is absurd to think that the business logic of a non-trivial business application can be neatly separated into just three components of a single MVC state machine existing at a single level of abstraction. And so I just don't get this idea of blurring, unless it is just one person's understanding of hierarchal abstraction layers that is blurred, which has nothing to do with a limitation of MVC.
The challenge is in how to create code on the browser that fully leverages the MVC pattern. If code is to be as well organized, refactorable, and maintainable on the browser side as it is on the server side, an MVC machine needs the full OOP paradigm for expression. That's why tools such as GWT have become so attractive. Tools as these make it practical and affordable to distribute all business logic, high and low, to the proper layer of abstraction -- be it at the widget level, tile level, page level, server level, system level, or enterprise level.