Differences between qomo and Ajax ~

Now Ajax is too powerful, so everything goes up. In fact, as early as 2000 ago, Web developers were already using frame/frameset for remote data acquisition. After ie became the de facto B-side standard, IFRAME became the "standard means" for remote data acquisition. -- For example, M $ uses this method to create the "huge tree" on the left side of the msdn website ".

Before the emergence of Ajax, this series of technologies were called "Remote Procedure Call", and open-source projects such as XMLRPC, httprpc, and phprpc were available. One problem with PRC is that an interface must be implemented on the S end, and the Code on the Web end agrees with an interface to describe the process name (procedurename) and the details of the parameter table. Among them, I like a project named "jsrs (JavaScript remote scripting)", which is implemented in multiple languages such as PHP and ASP on the sside.

There are also technical attempts to extend the RPC route. For example, some people use CSS or script labels to replace IFRAME for RPC.

The RPC era is the Ajax era. Ajax is intended to be "Asynchronous JavaScript and XML ". Originally, it was just a technical architecture. It is a technical method for data exchange between two ends of B/S. However, Ajax advocates the use of XMLHttpRequest to replace IFRAME in RPC technology. This enables a good user experience with "no interface refresh" in the browser. In addition, Google has successfully implemented "commercial quality Applications ". Therefore, Ajax technology is widely used. -- However, the (current) IFRAME compatibility is excellent only for cross-browser features.

Because Ajax uses XML as the specification for expressing data in the transport layer, it has a good multilingual encoding Foundation and can express complex data structures. This is incomparable to the traditional RPC method.

Aside from these features, Ajax is just a technical means.

However, Ajax enthusiasts are pushing Ajax applications to another "Realm ". Because Ajax uses XML, the object can be serialized as XML data on the s side; while on the B side, javascript is an object-based language with good logic processing capabilities. Therefore, XML can be interpreted as a client object. -- In terms of external performance, Ajax implements the ability to "push objects on the S end to the B end.

This is one of the main development directions of Ajax technology. "How to 'expression' and 'comprehension' objects in the same way on the S and B ends" and "serialize the object's executable capabilities, pushing to the B-end is a problem facing Ajax. The first obstacle is that JavaScript itself does not fully support "Object-Oriented", so it cannot express the characteristics of some send objects.

-- For example, if the send is. net, its object A has a reader (getter/setter) feature, so how does JavaScript understand the reader in object a when the object is serialized and uploaded to the B end? Therefore, Ajax is now tied to a "javascript with richer OOP features.

I think you should have seen the problem. What is the relationship between "Implementing richer OOP features" and "Ajax (asynchronous JS and XML? Ajax puts forward a language-level requirement, and some architectures/Projects implement these language features, and then bind them to Ajax. The larger Ajax is. Now Ajax has become "Implementation of language features + programming framework + technology", rather than Ajax technology itself.

Qomo does not investigate the evolution and deformation of such technology. Qomo focuses on some "Implementation of language features" and some "programming frameworks. Based on these two implementations, qomo provides a lightweight Ajax implementation framework and a lightweight Component Library (relative to FCL/VCL.

Since the features of qomo are mentioned here, I will transfer the description of my application for create project on SourceForge. You can perform comparative analysis on your own:

Qomo openproject is a true and full OOP framework and UI library.

{Note: # implemented, + implementing, * Planning,-tring}

Include features of OOP:
# Inhreited by class
# Attribute getter/setter
# Type system of Object
# Abstract and abstract exception
# Mutilcast event
+ Interface in Javascript
# Namespace System
# Package/unit import
# Tiny Ajax Architecture
+ SOA Architecture
* Template Programming
-More...

Include features of UI:
# Tidy component framework
# Graphics abstract level and a VML implement
# Database abstract level and a arraydb/filedb implement
# HTML element controller and some control component
# Bar, menu, window, etc. In virsual component library.
* More component, mount a tidy (very) FCL or VCL.
-More...

Other features:
# Some utils class.
# Auto class inhnert chart scan and generable
# Document generable tool (C # source)
# Testing and profing tools (JavaScript source)
-Oop core and UI can debugging and designing in vs. Net IDE.
-More...

The project extracted from a enterprise project. Free and Open Source for all JavaScript fans, and hope anybody join/impulse the project.