Google Chrome – Holy Smokes

The cats out of the bag, Google released their new browser, http://gears.google.com/chrome/. I was pretty excited about the new features that this browser would include, some of which are a brand new Javascript VM called V8, along with using Webkit for the rendering engine. The fact that each tab in the browser is its own process is also awesome news for web developers. I decided to take a run using it to run the web application I develop at my job, which is a large Case Management System by Justice Systems (http://www.justicesystems.com).

I decided to pick a fairly rich page with lots of content and javascript for the benchmark. This page has multiple tabs, and updates a client side data model as the user edits it. As far as page load times go, IE 7 and Firefox 2 were both right around 1.2 – 1.3 seconds just to render this page, and parse the javascript. Chrome comes in at 663 milliseconds, about 50% faster.

The next test I performed was toggling between tabs (YUI tabs). This toggling also involves some front end validation, storing and retrieving of client side data, so I figured it was a pretty good use case for testing out the new Javascript engine. IE 7 comes in at an average of 123 milliseconds to switch tabs, Firefox 2 at 143 milliseconds, and Chrome blows them away at 20 milliseconds.

With Chrome, Google is stating the the browser is a viable platform, which is great news for web developers who have started to see the limitations of current browsers. It makes sense that Google would be the one to push a browser like this, as many of their products are web-based, and rely on a performant browser. I can’t help but think that they have been waiting to see if other browser vendors could provide, but eventually just decided go ahead and get er dun’ themselves. Way to go Google, this is great news for users and developers.

  • del.icio.us
  • Digg
  • Facebook
  • Reddit
  • Twitter
  • Yahoo! Buzz
Tagged , | Leave a comment

Teaching an old Framework new tricks!

In summary, I want to discuss an alternative approach for developing a rich, dynamic UI using Struts1. The basic approach is:

  • Java Object to JSON string
  • JSON String consumed by Javascript
  • Manipulate UI, update Javascript model
  • On submit of form serialize Javascript model to JSON string
  • Set value of hidden input to JSON string
  • JSON string to Java Object on server side

Modern web development frameworks have come a long way, in almost every language. Many of the current popular frameworks have integrated widgets or processes for building rich ajax powered UI’s with little hand-rolled code. This makes developing those applications faster and easier. Unfortunately, we can’t always use the latest and greatest new framework as developers.

While working on a J2EE web application that was started over 5 years ago, I’ve learned a lot about how frameworks have evolved since then. When this project was started, Struts 1 was very popular, and a proven framework, so was naturally adopted for the front end. Over time, many things were built to integrate with Struts 1, but provide custom functionality that was required. This makes it very difficult, and highly improbably that a new front end framework can be swapped in due to time and money that would have to be invested. At some point that may be a necessity, but until then, you have to work with what you have.

Building a rich UI using ajax in Struts 1 is … interesting. Sruts1 is very form centric, and all of your form inputs in your UI map directly back to some field on your Java form object in one way or another. This makes it tricky to provide a flexible data structure for a rich UI that may be adding or removing elements. Try adding/removing elements to your page dynamically, and having them map back to your Struts1 Form in a clean way and you’ll see what I’m talking about. A recent approach I took to tackling this situation was to depend very little on the framework.

Lets say I have a Java object graph I want to load into some front end javascript model to work with in the UI. I can fetch this asynchronously as the page loads as a JSON payload, or just dump it to the page into the appropriate place so my javascript consumes it. Either way, I need to make sure its painless to convert this data structure to a JSON string, or create it from a JSON string. This will make passing it back and forth from the server side to the client side much easier.

I can then use this as my front end data model to display, change, remove and add data. When I’m ready to commit my changes, I then have to get that back to my server side Java action. Obviously I could also make the persistence portion asynchronous as well, but sometimes thats problematic, as you may have a lot that goes on in the backend and the rendering of a new page (security, alerts, etc.) that you would have to replicate if you were to do this asynchronously. To keep everything working as normal, one approach is to take your javascript data graph, and serialize it into a json string and set it into an html hidden inputs value. This input can be mapped back to your Struts form, so back in your action, you have a json string you decode and create the appropriate Java objects from. I’ve found this to be a very useful approach when trying to build a very rich UI on top of an older framework. In summary, here are the steps followed:

  • Build your data as Java objects that can be serialized into JSON, and created from a JSON string.
  • Consume the JSON data into your javascript and work with it as needed in the front end.
  • On submit of the form, serialize the Javascript object into a JSON string and set it onto the value of a hidden input
  • Get the value of the hidden input on the server side as your framework supports, and convert the JSON string back to your Java objects
  • Enjoy the praises as everyone is marveled at what you did (actually now days people already expect a rich UI, so you will probably just get to keep your job as the reward)
  • del.icio.us
  • Digg
  • Facebook
  • Reddit
  • Twitter
  • Yahoo! Buzz
Tagged , , , | Leave a comment

Javascript getFirstDescendantBy()


Update – Jan 22, 2009
A new native YUI function is in the works, and does this job better


Recently I was working on optimizing some javascript, and found a slow area that was trying to find the first focusable input in a certain area of the page, and it was taking anywhere from 100 – 500 milliseconds, depending on the size of the DOM tree in that element. After digging into it, I noticed it was using the YAHOO.util.dom.getElementsBy() method, which basically had to walk through the whole DOM tree in this case, testing each node against the boolean method passed in. After calling that, it would then return the first, if any, element that getElementsBy returned. Obviously this was a bad approach, as after you find the first match, there is no need to go further.

I did a little research, and saw that this had come up in a thread on the YUI group. I ended up writing a small method to fill in this functionality I wanted out of YUI, called getFirstDescendantBy(rootEl, method). Below is the code, the function takes a root element, or string id of that element, and then a function to test each element against that has the element being tested as the only input. This function passed in should return a boolean, and is similar to the way the YUI dom function getElementsBy works. Hopefully this will help out some people in similar situations.

function getFirstDescendantBy(rootEl, method) {
	var root = typeof rootEl === 'string' ? document.getElementById(rootEl) : rootEl;
	var firstDescendant = null;
	var children = root.childNodes;
	for(var idx in children) {
		var child = children[idx];
		if(child.nodeType === 1) {
			if(method(child)) {
				firstDescendant = child;
				break;
			}else if(child.childNodes.length > 0) {
				var recursiveResult = getFirstDescendantBy(child, method);
				if(recursiveResult !== null) {
					firstDescendant = recursiveResult;
					break;
				}
			}
		}
	}
	return firstDescendant;
}
  • del.icio.us
  • Digg
  • Facebook
  • Reddit
  • Twitter
  • Yahoo! Buzz
Tagged , | 4 Comments

Back to Firefox 2

If you’re like me, you use Firebug a lot, like, all day long. Long gone are the days of resorting to alerts. The worst I’ll fall back to is using the YUI logger for IE.

I’ve recently been having a lot of issues using Firefox 3, and Firebug. Firefox 3 has been pretty consistent at crashing a few times throughout the day. Firebug 1.2 has recently been causing me more and more troubles, to the point where I can’t get it to not stop at breakpoints that I’ve removed, or it stops at my breakpoint, but doesn’t let me play it through or debug, or remove the breakpoint, because it doesn’t show up as being registered.

I’m sure these are hiccups with the new version of Firefox 3, but it is pretty disruptive to me as I’m developing. I reverted back to Firefox 2 and an older version of Firebug until they get this sorted out, which I’m sure will be soon. For anyone looking, you can find old versions of Firefox on FileHippo, and past versions of Firebug from the normal download site.

  • del.icio.us
  • Digg
  • Facebook
  • Reddit
  • Twitter
  • Yahoo! Buzz
Tagged , | 1 Comment

Complex Javascript Event Handling: EventMediator

A large enterprise sized project I work on uses YUI library extensively, and events are a huge part of the rich front end we’re developing. What you start to learn quickly about UI events, is that dependencies between different events start to get very complicated very fast. When A depends on B, but B needs to wait for C and D and E to finish, but E needs to wait for F to finish, you have a complex situation on your hands. Up until recently we were able to rely mostly on just using CustomEvents in YUI to handle this for us.

Where that starts to break down is when you have one event, A, that is dependent on multiple other events, B, C, D. You now have to manually keep track of what has fired, and make sure you don’t fire that A until B, C and D have all fired. With very little code, here is a simple class that can be used in conjunction with YIU CustomEvents. It will handle the ‘book-keeping’ of firing what you want when all the events you have designated fire.

EventMediator = {
	addActivationRecord : function(record) {
		record = record || {};
		var that = this;
		for(var idx in record.events) {
			var eventRecord = record.events[idx];
			if(eventRecord.event !== null) {
				eventRecord.fired = false;
				eventRecord.event.subscribe(function(scopedEvent) {
					return function(e) {
						scopedEvent.fired = true;
						that.fireActivation(record);
					}
				}(eventRecord));
			}
		}
	},
	fireActivation : function(record) {
		var fired = true;
		for(var idx in record.events) {
			if(record.events[idx].fired === false) {
				fired = false;
				break;
			}
		}
		if(fired === true) {
			record.activate.call(record.scope);
		}
	}
};

Using the EventMediator would look something like the following:

EventMediator.addActivationRecord({
	events : [
		{ event : myObj.someYUICusomEvent },
		{ event : myObj.anotherYUICusomEvent }
	],
	activate : myObj1.myActivationCallback,
	scope : myObj1
});

It’s pretty straightforward I think. You call addActivationRecord, passing in an array of objects, whose ‘event’ property points to a YUI CustomEvent. You also provide an activate callback method, and give it a scope in which to call the method. For my purposes so far this has worked pretty well, although I’m sure it could be built up to be much more robust. Hope it helps someone out!

  • del.icio.us
  • Digg
  • Facebook
  • Reddit
  • Twitter
  • Yahoo! Buzz
Tagged , | 4 Comments

Page optimized by WP Minify WordPress Plugin