Web Info & Tutorials

The 100+ members of OpenAjax Alliance recently approved the release of OpenAjax Hub 1.0, including the OpenAjax Hub 1.0 Specification, an open source reference implementation at SourceForge, and a complete test suite. OpenAjax Hub 1.0 is a small JavaScript library (<3K) that allows multiple Ajax toolkits to work together on the same browser frame. The central feature is a publish/subscribe event manager, which enables loose assembly and integration of Ajax components. OpenAjax Hub 1.0 allows multiple conformance options for Ajax libraries, some of which require only a couple of lines of new code. Some existing Ajax libraries, such as Dojo 1.0, bundle OpenAjax Hub 1.0 within their distribution.

The alliance’s second-generation initiatives will focus on secure mashups. OpenAjax Hub 1.1 will add support secure mashups, publish/subscribe across browser frames, and publish/subscribe between clients and servers (including Comet-based communications). A complementary second initiative, OpenAjax Metadata, will define industry standard Ajax library metadata that will be used by Ajax developer tools (i.e., IDEs) and mashup editors to create improved user experiences. OpenAjax Metadata will define:

• Standard XML metadata for “widgets”, where widgets can be either the various UI controls found in Ajax toolkits or can be mini-applications such as Google Gadgets that can be used as components within a mashup. This metadata will allow Ajax IDEs to auto-populate widget palettes and property editors.
• Standard XML metadata for JavaScript APIs, which will allow Ajax IDEs to deliver intelligent code-assist features to JavaScript developers.

The alliance also will provide open source transcoders that allow existing proprietary widget/gadget technologies, such as Google Gadgets, to work with Hub 1.1 and OpenAjax Metadata, plus an open source mini mashup framework that leverages OpenAjax Hub 1.1 and OpenAjax Metadata. Early versions of these open source initiatives can be found at the OpenAjax Alliance project at Sourceforge.

Reposted from my personal blog

As soon as I started to play with Aptana Jaxer, I saw an interesting opportunity to port the Google Gears Database API (note the Gears in the logo!)

If I could use the same API for both client and server side database access, then I can be enabled to do things like:

• Use one API, and have the system do a sync from local to remote databases
• If the user has JavaScript, use a local database, else do the work remotely
• Share higher level database libraries and ORMs such as Gears DBLib for use on server side data too

I quickly built a prototype to see if this would all work.

The Jaxer shim of the Gears API was born, and to test it out I took the database example from Gears itself and made it work.

To do so, I only had to make a few changes:

Run code on the server

I changed the main library to run on the server via:

I wrapped database access in proxy objects, such as:

This now allows me to run the addPhrase code from the browser, and it will be proxied up to the server to actually execute that INSERT statement.

This forced me to separate the server side code from the client side code, which is a better practice anyway, but it does make you think about what goes where. In a pure Gears solution I can put everything in one place since it all runs on the client.

Create the new gears_init.js

A new gears_init.js acts as the shim itself. Instead of doing the typical Gears logic, it implements the Gears database contract. This wasn't that tough, although there are differences between the Gears way, and the Jaxer.DB way. The main difference is to do with the ResultSet implementation, where Gears goes for a rs.next()/rs.field(1) type model versus the Jaxer.DB rs.rows[x] model.

I actually much prefer Gears DBLib as it hides all of that, and just gives the programmer what he wants... the rows to work on.

oncallback magic

In the current Jaxer beta, I ran into an issue where I wanted the Gears library to just "be there" for any proxy requests.

You have to think about the lifecycle of a Jaxer application, and the documentation tells you what you need to know to work around the issue.

In this case, I wrapped the code in:

This is less than idea, and Aptana is playing with nice scoping which would enable you to just say "hey, load this library once and keep it around for the lifetime of the server | application | session | page". That will be very nice indeed.

You can do a little bit of this by opening up your jaxer_prefs file and adding the resource for your file:

Future...

This is just the beginning. As I mentioned at the beginning, I am interested to see where you can take this to handle clients who do not support JavaScript, and also to deal with synchronization with minimal code (sync from local to remote with exactly the same SQL API).

John J Barton has been working hard on Firebug 1.1, but the work has been in the dark a little unless you are paying attention.

He has been putting releases up, and Kris Zyp has been kind enough to host

I have talked to a few people recently who keep Firefox 2 around just "because Firebug needs it" but the latest beta works great in Firefox 3 (which I find to be a huge leap on the Mac).

The beta features:

• eval() debugging,
• external editor interface,
• browser-generated event handler debugging,
• executable lines marked with green line numbers,
• user-controlled naming of eval() buffers,
• Stack side panel on "Script" panel for callstack,
• Supports Firefox 3,
• "better" debugging icons,
• CSS errors report against source lines,
• bug fixes (incl. issues 8, 69, 218, 230, 239, 249, 269, 314, 321, 345)
• Internal firebug debug output

I raise a drink to John for keeping Firebug going strong!

I met this really nice bloke at the first Ajax get together, put on a few years back, by O'Reilly and Adaptive Path. Ben and I were arguing about something or other and this guy politely told us that we were totally wrong. It turned out to be Kevin. He is a really nice chap, and is really interesting to talk too. You delve into his technical background and it is deep. Really deep. Ever play with the Newton?

Well, Kevin has been promoted to become CTO of Adobe. The press release positions it as "marking an increasing significance for Rich Internet Applications across Adobe’s business".

All I care about is that we have a real techie who does the right thing in a more powerful position at Adobe. Hopefully Flash will be open sourced soon huh Kev? Congrats.

In this new position, Lynch will oversee Adobe’s experience design and core technology across business units. As part of this role Lynch will continue to drive Adobe’s technology platform for designers and developers, which includes Adobe Flash Player, Adobe Flex, and Adobe AIR, the new cross-operating system application runtime that bridges the computing power and data capabilities of the desktop with the real-time dynamic capabilities of the Web.

And for old times sake.....