You know I like standards.
Even if it is some kind of more complex to implement a solution based on a standard than using a direct and efficient but proprietary way, there are benefits on the long way that I just don't want to miss: the ideas and thoughts of others materialized in APIs, specifications and best practices.
That's why I use the SOAP standard webservice protocol for my Ajax implementations.
Now OpenAjax Alliance is another try of a group of about 75 companies and organizations to define standards in the Ajax hemisphere. There are a lot of ideas and some good ideas too in the current discussions. We all know that it is hard to define a standard specification that gets agreed by the majority of the members. And it can take a long time until a standard proposal is adopted.
Right now a version 1.0 of the specifications are on their way and they contain some good stuff that I like to bring into the Aspects of Ajax framework and support an probably upcoming standard this way.
Libraries and Namespaces
Did you try to use 2 libraries that both register the $() function but implement it differently?
The OpenAjax registerLibrary and unregisterLibrary methods that can be used to help mastering this problem space.
The ajax, the proxies and the jcl prefix will be used by the Aspects of Ajax framework because these are the names of the global variables I use (beside minor important stuff). I hope and pray that nobody else will use this prefix in any other AJAX framework. (I am the first - I won! :-)
No, and seriously: I don't like the global ajax variable being registered by any framework and right now I am not happy about this early (2005) decision any more.
The namespace used by the Aspects of Ajax frameworks will be de.mathertel because http://www.mathertel.de/AJAXEngine/ is the URL where the documentation and the samples can be found on the web.
... but maybe it's time to register a product name related web address :-)
When implementing a standalone AJAX framework you do not have to care about these problems. Being compatible (and friendly to other frameworks) can open a wide space in combining functionality from different sources.
Events - inter controls connections
So it's a good thing to define a common functionality that does the job and that controls can use to talk to each other using the well known subscribe and publish pattern and the idea of events.
The Aspects of Ajax framework has a small implementation since almost 2 years (see http://ajaxaspects.blogspot.com/2005/09/connecting-controls.html) called "page properties" or data connections that also allows this kind of connectivity through the DataConnections object but compared with the event system of the OpenAjax hub specification there are some pros and cons.
- The OpenAjax hub has defined an idea of namespaces and namespace notation like the namespace ideas known from .NET, Java and other environments. Events that are published are prefixed by a namespace so different providers of the same event name can be distinguished. The page properties of the Aspects of Ajax framework only had one global namespace (the page).
- Using the OpenAjax hub specifications it is possible to subscribe to specific events by specifying the long name of the event and by using a wildcards for registering to multiple events. In the Aspects of Ajax framework it was possible to subscribe to all events.
- The Aspects of Ajax framework has a mechanism that allows to poll for a current value of a prior published property change / event. The OpenAjax hub has no such methods defined but it is easy to implement an invisible control that logs all changes and offers some methods for getting the latest values.
- The Aspects of Ajax framework has some specific controls that helped while developing. One of them is a log of all events and the new values. Beside the changed implementation they also have a new parameter to specify what specific namespace they should watch.
Overall the OpenAjax implementation has some big advantages over the older DataConnections and the additional functionality can be added.
The size of the implementation
As of this writing the (unfinished) reference implementation is about 2801 bytes. The (current) implementation available on my side at http://www.mathertel.de/OpenAjax is about 1300 bytes. Maybe my implementation is a little bit slower because I rely on regular expressions but I have not done any detailed measures yet. Both sizes are calculated by comparing a shrinked version using the tool from the dojo framework that is available online at http://alex.dojotoolkit.org/shrinksafe/. This is because I don't want to compare the comment lines or different programming styles.
I will have a look for the specification of the OpenAjax Alliance hub and I will post a compatible version. It is just good to have a second source.