Posts Tagged ‘AJAX’

* JavaScript Pub Sub

Posted on April 28th, 2009 by Dave Johnson. Filed under JavaScript, Uncategorized.

I was talking to someone the other day about the observer pattern in JavaScript and I was reminded about this JavaScript method that is part of Complete UI.

nitobi.Event.prototype.subscribeOnce = function(method, context) {
  var guid = null;
  var _this = this;
  var func1 = function() {
    method.apply(context || null, arguments);
  guid = this.subscribe(func1);
  return guid;

subscribeOnce is a special sort of event subscription that rather than being being executed every time the event fires, the handler function is only executed once and then automatically unsubscribed from the event. It is obviously most useful for initialization stuff in JavaScript. There is some more info on JavaScript pub sub over on Ajaxian too.

Tags: , , , .

* Surfin’ Safari

Posted on October 9th, 2008 by Dave Johnson. Filed under AJAX, CSS, JavaScript, XML, completeui, quirks, safari.

For the past little while I have been busy fixing up Complete UI to work in Safari. The big problem for us in getting Complete UI working in the WebKit powered browser was that there was no client side XSLT JavaScript API until Safari 3.

So there were a few things I had to update to get things all working properly - and this more or less applies to Chrome now as well but I need to check on a few things.


The first problem I came across was using the XMLDocument::selectNodes method. To get selectNodes working I had to implement my own NamespaceResolver which is usually handled for you by the browser.

I had to change the call to the XMLDocument:evaluate method a bit to look like this:

var oResult = this.evaluate(
  new MyNSResolver(),

Where the MyNSResolver class essentially implements the lookupNamespaceURI method through a switch statement returning the appropriate URI for the specified namespace prefix. Pretty easy but kinda annoying to figure out!

function MyNSResolver() {};
MyNSResolver.prototype.lookupNamespaceURI = function(prefix) {
  switch (prefix) {
    case "xsl":
      return "";
    case "ntb":
      return "";
      return null;

XSLT Transformations

Then there was the actual act of performing an XSLT transformation. Doing the transformations was fine but getting the output node or string from the transformations - depending on if the <xsl:output /> was text, html or xml - was rather different than both Firefox and Internet Explorer. Go figure.

For transforming to an XMLDocument here is what I found to be the output of an XML transformation for the various output methods.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="">





XSLT Parameters

There is also one difference in how the Safari XSLT processor deals with parameters. Rather than casting true / false to 1 / 0 the Safari XSLT processor does not recognize true or false values and requires the inputs to be 1 / 0. I have started setting all my XSLT params like this:

oXsltProc.addParameter("paramName", val+0, "");

Events and Focus

There were some other small issues that I came across regarding implementing rich keyboard navigation and events in general.

For example, in our Grid component I had to change the HTML element that we used to “focus” the Grid so that we could capture key presses from a <DIV> to an <INPUT>. Apparently you can’t call Element:focus on a <DIV> element from JavaScript but you can on an <INPUT> (even with a tabIndex set but I try to avoid those for accessibility reasons anyhow).

However, that was not my only problem with keyboard navigation. The other problem was that the focusable element (the newly created <INPUT> in this case) was still not getting focus due to a small code snippet like this:


That second line where I cancel the event (wrapped nicely in a cross browser library call) somehow prevents the <INPUT> from getting the focus. Never figured out a workaround aside from a browser check before calling cancelEvent.


Finally, in some of our components we also generate CSS using XSTL and dynamically insert it into the page. For example, the developer defined column widths in a Grid produce dynamically generated CSS. However, WebKit does not seem to support the bulk creation of stylesheets neither using the document.createStylesheet method of Internet Explorer nor the hacky way of doing in Firefox by creating a <STYLE&gt element and setting the innerText. Instead Safari requires that you use the uber slow DOM API for adding rules to stylesheets :(


You will often see the “xml namespace prefix mapped to wrong URI” error when working with XSLT in Safari.

Be careful that you are using double quotes in your XSLT for attributes etc and only use single quotes in attribute values.

Of course you also have to be very careful about the nodes that you are transforming / selecting as you are also likely to get the “WRONG_DOCUMENT_ERR” fairly frequently.

Oh yah and depending on the application expect a lot of random “Stack overflow” errors!

Tags: , , , , , , , .

* Complete UI Q4

Posted on September 26th, 2008 by Dave Johnson. Filed under AJAX, JavaScript, Nitobi, completeui.

Some big changes are coming in the Q4 release of Complete UI. Big!

Of course there is a slew of JavaScript bug fixes for all the components with Grid receiving the most attention for IE 8, Safari 3, Firefox 3 and Chrome.

There are a bunch of changes to the Java side of Complete UI with more great JSP and JSF code to make it even easier to use Complete UI in your Java project.

Finally, we have also made huge changes to the ASP.NET Grid and Combo code - and are working on the rest of the components as I am writing this! I think that anyone using ASP.NET will be very happy with the new direction of the ASP.NET code :)
We are shooting for an on time Oct 1 release but there is so much we are trying to fit in it might be a bit late - but it will be well worth waiting for!

Tags: , , , , , , , .

* AIR Support

Posted on September 4th, 2008 by Dave Johnson. Filed under AJAX, air.

When Andre went on the final leg of the Adobe AIR tour back in the spring I needed to build a nice Ajax + AIR demo for him. Ultimately I had to drop the project and Andre went without. The main reason that I decided not to build the application was due to frustrations with building HTML / Ajax apps in AIR - though I had previously built several successful HTML / Ajax AIR apps in the beta versions of the AIR runtime.

This was the first real application that I had tried to build since the Beta 1 and of course there were some API changes - as can be expected between beta versions and a release - but more importantly the security restrictions in Ajax AIR applications make it almost unusable for certain use cases. At least for my HTML apps.

There are two main problems that I found exceedingly annoying and that ultimately led to the shelving of the project.

The first problem was that you cannot use innerHTML to insert HTML that contains event handler code such as <div onclick=”foo()”>Bar</div> when you are in the Application Sandbox. This is of course to prevent people from inserting malicious code on HTML events - which is equivalent to doing an eval if the user somehow triggers that event or the event is triggered manually through JavaScript.

That meant that I had to put most of my code in the Network Sandbox to get around the security restrictions. Fair enough I thought until Murphy reared his ugly head.

It just so happens that you cannot pass complex objects across the Sandbox bridge since they become of type “Object” on the other side. So for example I wanted to pass an XML document from the Network Sandbox where my application UI is residing into the Application Sandbox so that I can do some cross domain requests with it and / or save it to disk for use later when offline - essentially to do anything interesting it needs to be in the Application Sandbox. So to do this I had to write my own code to serialize and deserialize any custom objects that I wanted to pass around, essentially converting my XMLDocuments and so on to strings on one side and then loading them into XML documents again on the other. Pain. In. The. Arse.

A second, and maybe more important result of not being able to pass complex objects across the bridge is that it pretty much means that if you want your UI to be in the Network Sandbox you cannot do file drag and drop unless you have a special place that is in the Application Sandbox where the user can drop onto. This may not seem like such a big deal, however, it poses other problems with the UI layout since the best way to layout the UI in an HTML AIR app is to have the custom chrome in the Application sandbox using the CSS border-image (which is awesome) and then have the rest of the UI in a 100% width and 100% height IFrame with some margin to take into account the custom chrome edges. In that case there is not really any opportunity to have a special drop area in the Application Sandbox to accept dragged information from the desktop.

So to make a long story short, building AIR apps that use dynamic UI generation and some of the APIs that make AIR awesome, like drag and drop, means that HTML / Ajax AIR apps are simply not feasible due to the security restrictions.

Tags: , , , .

* Enterprise Ajax Live Lessons

Posted on August 13th, 2008 by Dave Johnson. Filed under AJAX, Nitobi.

Get it while it’s hot! It looks like the Enterprise Ajax Live Lessons are now available on either Safari or Amazon.

if you want to learn about Ajax in a format that is bit more easily digestible than reading a boring book then be sure to pick up the Live Lessons where we step you through all the pitfalls of building an Enterprise Ajax application. Topics covered include a framework review, testing, security and usability.

Go get it!

Tags: , , .

* What is RIA?

Posted on August 12th, 2008 by Dave Johnson. Filed under AJAX, Conference, RIA, Web2.0.

Way back in May of this year (I have been thinking about this post for a while now!) Andre and I were down at JavaOne to give a presentation and also had the chance to take part in the always interesting (at least two years in a row now) RedMonk CommunityOne session. It was good to take part in the cloud computing, twitter and open source discussions - one great take away was “don’t drink and tweet”. I digress.

Of most interest to me was the round table discussion about “what is an RIA?“. There were various opinions on this that I will not repeat here and let you read over on RedMonk.

What didn’t come through on the RedMonk review was what I thought, arrived at through the great discussion, was really the defining characteristic of Rich Internet Applications. In the end it was not about flashy graphics or animations. The one defining characteristic of an RIA is that there is no page refresh.

That’s it. That is all there is to RIA. If you have an application running over the network that does not have a page refresh then that is an RIA - be it using Flash, Ajax or a Java Applet. The discussion went back and forth until Jeremiah Stone from SAP finally talked some sense (afterwards we had a very interesting discussion and I really need to follow up with him) saying that good design is dependent on the context of the problem being solved. Now this is a really important idea since if you are used to working with a keyboard accessible green screen application, a visual mouse driven GUI will probably be far less usable. It is all context dependent. I may take longer to learn the green screen application but it will likely pay dividends in productivity down the road.

At any rate, long story short, the one common theme that people presented was that an RIA is defined by an application that has no page refresh, whether it is made for a user of a terminal or a new web 2.0 application.

I had my epiphany at the very end of the session and was pretty much lost on deaf ears of people who were about ready for a cold one (aside from Duane who was thoroughly liquored already ;)) . However, I felt somewhat vindicated when I was reading James’ post about the session when I noticed that there was a comment from David Mendels of Adobe, who was possibly responsible for defining the term while at Macromedia in the early 2000’s. Indeed David suggested that the original definition of an RIA was an application with no page refresh.

Based on that I think that the case of the meaning of RIA can be considered closed.

RIA == No page refresh


Tags: , , , , , .

* Hack Day Results

Posted on June 9th, 2008 by Dave Johnson. Filed under AJAX, Flex, Nitobi.

Despite it occurring on one of the nicest days of the year so far in Vancity, sixteen people came over to the Nitobi offices and hacked the day away. The beer arrived early so those of us who’s projects made a turn for the worse were getting sauced already by two or three - just after the pizza lunch.

When everything was said and done, Yohei came out on top with a Papervision3D version of the Nitobi office! It was pretty damn cool and you can play with it below.

Alexei also showed his NitobiBug tool that is a cross-browser Ajax debugging tool similar to FireBug.

Thanks to everyone for coming out despite the amazing weather (which you can see out the windows of the model of the office below) and the opening of the new Vancouver Apple store :)
We will be having the next one some time in the fall I think.

Tags: , , , , , .

* Complete UI JSF

Posted on May 15th, 2008 by Dave Johnson. Filed under AJAX, JSF, java.

Mike has written up about our JSF preview that we released last week, which can be downloaded here.

We are pretty excited to be improving our Ajax support on the Java platform and this release is just a glimpse of what we have in store for JSF!

Check it out and get us your feedback please!

Tags: , , .