Web Info & Tutorials

In an ongoing exercise to become more familiar with MooTools and Canvas, Greg Houston has created an extension to MooTools called Mocha UI which provides a new UI class made with canvas tag graphics.

The new class provides the following set of features:

• No images. The windows, including their controls, gradients and shadows, are drawn with the canvas tag.
• Adjustable rounded corner radius.
• Windows can be focused, dragged, resized, maximized, restored down and closed.
• Dynamically create new windows on demand.
• Fullwindow window size is adjusted if the browser window size changes.
• Minimal HTML markup required.
• Tested in Firefox 2, Internet Explorer 6 & 7, Safari 2, and Opera 9.

Greg is also considering the following enhancements:

• Create custom canvas scrollbars.
• Add a modal window.
• Create more class options.
• Add minimize to windows.
• Add a sortable dock.
• Make shadows easier to adjust.

The folks at Gaia Innovations recently released their newest version of the Gaia Ajax Widgets suite, code named Victory. The suite, which caters to .Net and Mono developers, makes adding Ajax and UI capabilities to .Net applications substantially easier and comes in a variety of licenses.

Apart from normal upgrades and code improvements that are to be expected in a major release, the biggest enhancements for this release were the additions of ViewPorts and Aspects.

ViewPorts

Inspired in part by ExtJS, the new ViewPorts feature provides the ability to create a flexible layouts for building your web applications.

Ajax Aspects

Ajax Aspects allow you to dynamic assign unique behaviors to widgets, essentially extending out the core functionality and providing a wealth of capabilities.

You could take an Image Widget and make that image resizable, simply by attaching an AspectResizable to that image. Add another line of code, and suddenly you can respond to the resized event in you code-behind on the server!

Aspects have tripled the potential of Gaia because you can combine them to form new functions. With 7 Aspects and 33 widgets that’s theoretically 231 new features by itself ;) Of course, some aspects aren’t relevant for some widgets.

A video has been created to better demonstrate the capabilities of aspects and can be viewed here (scroll down to see it).

One area where Gaia has lacked (self-admittedly) has been on the UI. With a strong focus on server-side bindings, they’re not refocusing their efforts to improve the UI of the library:

Gaia Ajax Widgets have always suffered from being the “less visually appealing” Ajax Library since they have focused a lot on making the server-side bindings against ASP.NET and Mono and the internal core of their library have gotten more focus. Now the core or the foundation is mostly 100% finished and very stable and we can focus on more “eye-candy” and “bling” to make our library visually appear as great and beautiful as some of the more popular JavaScript libraries like ExtJS and Dojo etc. No doubt that creating the “Custom JavaScript free Ajax Library” has had it’s costs. Now let’s hope it’s time to reap.

In addition the Gaia team has worked on improving the size of the codebase reducing the code per widget by up to 60%. With load times always being a concern, that’s great news for Gaia customers.

Rakesh Pai has written up a piece on GData JavaScript client library (video), CrossSafe, and SubSpace.

He discusses the high level, and then delves into the requirements and process for getting cross domain code working:

Here’s what you require to get cross-domain read write JavaScript APIs to work.

• The “setup” required at the client’s end is that he should have at least one static cacheable resource embedded in the page where he’s consuming the API, which is loaded from the same domain as his page. This could be in the form of a static CSS file, or an image. If the page doesn’t have either, it will be required to insert one – maybe in the form of a 1px image hidden away by using inline style attributes. This is usually not too much to ask for, considering that pages are either made up of spacer GIFs or CSS documents, usually loaded from within the same domain. The static resources I mentioned could even be from a different sub-domain within the same domain, but it might complicate scripts slightly to have it set up that way. If this setup is not possible at all (oh, come on!), you could still find a work around², but I think that this is the easiest way to get things up and running.

• You will need to do some setup at your end, if you are the creator of the API. In particular, you will need to setup a “proxy” page that intercepts the requests from the JavaScript client API, conditions the data, and passes it along to the REST API. This proxy page also reads the response from the REST API, conditions the data to suit the client, and flushes it down to the JavaScript.

Now, let’s go over the process of actually orchestrating the communication.

1. The API client library is included on the page by means of a script tag pointing to your domain (your domain being the host of the client library). This is similar to including the Google Maps API on the page.

2. Once included, the script scans the page for the static resource mentioned above. This is done by walking the DOM looking for link or img tags, and checking the value of the href/src attribute to ensure it lies within the same domain as the calling page. The URL of this resource is stored for use later. At this point, if required, the client library can signal to the developer that it is ready for communication with the server. If the resource is not found, the client-library should throw an error and terminate.

3. When a request requires to be made, the client library takes the request parameters and prepares the markup for a form. This form can have any method attribute value, and should have it’s action attribute set to the proxy page on your domain. The parameters to be sent to the server should be enumerated as hidden fields within the form. The client library also specifies the resource (in a RESTful sense) that needs to be acted upon. Also, the name of the static resource we had hunted down earlier is passed on to the server. This form is not appended to the document yet. This markup is then wrapped into <html> and <body> tags. The body tag should have onload=”document.forms[0].submit();”.

4. The client library then creates a 0px x 0px iframe, without setting the src attribute, and appends it to the page’s DOM. This makes the browser think that the iframe exists in the same domain as the calling page. Then, by using the iframe document object’s open(), write() and close() methods the markup created in the previous step is dumped into the iframe. As soon as the close method is called, the form gets submitted to the proxy page on your domain because of the onload in the body tag. Also note that this gives the server access to any cookies it might have created from within it’s domain, letting you do things like authentication. In this way one part of the communication is complete, and the data has been sent to the server across domains. However, the iframe’s document.domain has now switched to point to your domain. The browser’s security model now prevents any script access to most parts of the iframe.

5. The proxy page sitting on your server now queries your REST API – basically doing it’s thing – and gets the response. Response in hand, the proxy is now ready to flush the response to the client.

6. If the response is rather large in size, as might be the case with a huge GET call for instance, the proxy breaks it up into chunks of not more than say 1.5 kb².

7. The proxy is now ready to flush the response. The response consists of iframes – one iframe for each of these 1.5 kb chunks. The iframe’s src attribute is set to the static resource we had discovered earlier. It is for exactly this purpose that we had hunted the resource down and passed on the URL to the server. At the end of each of these URLs, the proxy appends one of the chunks of the response, after a “#” symbol, so that it works as a URL fragment identifier. Also, the iframe tags are each given a name attribute, so that the client script can locate them.

8. Meanwhile, the client-side code is where it had left off at the end of step 4 above. The script then starts polling the iframe it created to check for the existance of child iframes. This check of iframes will need to based on the iframe name the server will be sending down. It will look something like this: window.frames[0].frames[“grandChildIframeName”]. Since the static resource we have loaded into the grandchild iframe is of the same domain as the parent page, the parent page now has access to it, even the intermediate iframe is of a different domain.

9. The client script now reads the src attributes of the iframe, isolates the URL fragments (iframe.location.hash), and reassembles the data. This data would typically be some JSON string. This JSON can then be eval’d and passed on to a success handler. This completes the down-stream communication from the server to the client, again across domains.

10. With the entire process complete, the client-library can now perform some cleanup actions, and destroy the child iframe it created. Though leaving the iframe around is not a problem, it is not necessary and simply adds to junk lying around in the DOM. It’s best to get rid of it.

Michael Carter wrote most the trials and tribulations of getting protocol moving with IE. He knew that the htmlfile ActiveX object was the key, but kept effort errors.

Then he stumbled on the solution:

We hap to be in luck. Changing JavaScript variables, including Array functions, seems alright as farther as the gods of htmlfile moving are concerned. So our resolution is to only attach circumstance payloads to an clothing from within the iframe, hit the parent pane ingest ingest a official wrap (’setInterval’) to periodically analyse the clothing for newborn messages, and then transfer them to the callback. It’s not as foppish as I’d like…but it beatniks every the added techniques I’ve tried.

Why not meet call a duty bespoken the parent window, you wonder? It turns discover htmlfile’s iframe doesn’t tending where the duty goal lives; instead, it cares which arrange is utilised to fulfil the code. The htmlfile arrange is a arbitrary beast, and module protest when engaged to do likewise such DOM work. The gist of setInterval is to advise the actualised DOM manipulations to a arrange that is dead innocuous for that variety of scripting. This mend entireness for IE 5.01+.

Michael meet place up added place that details the solution after acquisition most the nuances of IE. He ended up using the mass code:

And in the iframe:

Ben and I are in London, enjoying the rain, as we move in the @media Ajax word in Westminster. We got to provide our farewell come incoming to borough Abbey at the aforementioned instance that the Queen and every of the house were celebrating her 60th ceremony anniversary. Awwww.

As per usual, we were employed on the slides a lowercase at the terminal time as we got unitedly and at 4 a.m. we someways got sidetracked as we went finished a ordered of slides on the grouping behindhand the ECMAScript 4 debate. We ended up having a lowercase recreation with our motion on Kevin Lynch, and ended up with this:

Jon Davis has created CacheFile, a place to store versions of common libraries such as Dojo, jQuery, Ext, Prototype and more. Dojo has a nice CDN already thanks to AOL, and YUI thanks to Yahoo! The other libraries don't have the same, so this could be the solution:

CacheFile.net is an HTTP web server that contains common Internet resources that are frequently reused on other web sites. It exists to alleviate the need for a common root URL for web resources that are otherwise not directly linkable at their primary URLs.

For example, popular Javascript libraries may have a direct download link for a specific version of their script files, but may discourage the direct linking of these files on their site. People are instead encouraged to download the scripts and manage them on their own servers. But the problem with each web site retaining its own copy of the same resources is that web users must re-download them all over again as they navigate from site to site. Over browsing five different jQuery-driven web sites using the same version of jQuery, there may be five different copies of the script being seperately downloaded.

You can take a peek at the listing of scripts and you can even grab a versioned file while setting the expires tag that you want:

I am all for this idea. I want a central set of resources to host JavaScript files so browsers can do smart things and have special versions for browsers cached etc. The only issue with this particular site is:

• They could turn it off at any time (and mention this on the home page)
• Trust. We need some kind of trust relationship. I am sure Jon is a good guy, but if he wasn't he could switch out the libraries. Or, not in a malicious way, the files could be incorrect
• CDN. AOL and Yahoo! use CDN's to serve their files

I applaud Jon for doing this though!