Prototype approach

This approach basically creates an instance of the javascript widget for each input field, and the javascript widget object utilizes the prototype definition so the internal functions can be defined once in memory. Below is an example of what a simple DatePicker widget that “wraps” the YUI Calendar widget, would look like:

function DatePicker(icon, field) {
    this.icon = icon;
    this.field = field;
    YAHOO.util.Event.addListener(window, 'load', this.initialize, this, true);
}
DatePicker.prototype = {

	icon : null,

	field : null,

	calendar : null,

	id : 'date-calendar',

	container : null,

	initialize : function() {
		YAHOO.util.Event.addListener(this.icon, 'click', this.click, this, true);
		this.renderContainer();
	},

	renderContainer : function() {
		this.container = document.createElement('div');
		this.container.style.display = 'none';
		document.body.appendChild(this.container);
	},

	click : function(e) {
		if(this.calendar === null) {
			this.renderCalendar();
		}
		this.calendar.show();
		this.positionCalendar();
	},

	renderCalendar : function() {
		this.calendar = new YAHOO.widget.Calendar(this.field+'-calendar', this.container, { title:'Choose a date:', close:true, navigator: true } );
		this.calendar.selectEvent.subscribe(this.populateDateField, this, true);
		this.calendar.render();
	},

	positionCalendar : function() {
		var position = YAHOO.util.Dom.getXY(this.field);
		position[1] = position[1] + 25;
		YAHOO.util.Dom.setXY(this.container, position);
	},

	populateDateField : function() {
		var date = this.calendar.getSelectedDates()[0];
		YAHOO.util.Dom.get(this.field).value = date.getMonth() + '/' + date.getDate() + '/' + date.getFullYear();
		this.calendar.hide();
	},

	hide : function() {
		if(this.calendar !== null) {
			this.calendar.hide();
		}
	}

};

The html for creating this widget is as simple as follows:

<script type="text/javascript">
	new DatePicker('date-icon', 'date-field');
</script>
<label>Date: </label>
<input type="text" name="date-field" id="date-field" />
<img src="images/calendar.png" id="date-icon" />

Some benefits to this approach are that the instance of the widget object has direct references to the input id and calendar icon id, and nothing has to be ‘inspected’ at runtime execution of the events. This leads to some cleaner code on a small level. It also has some downsides as we’ll discuss below

Singleton approach

The Singleton approach creates a ’singleton’ wrapper object that creates ONE YUI Calendar widget that is re-used across all input fields. At runtime, the icon clicked on is used to determine which input field is in use through an extra attribute added to the icon image called ‘field’ that contains the id of the input it is linked to. This extra attribute could be avoided by getting the icons previous sibling if it it important to you to validate your html. This code would look as follows:

DatePickerSingleton = {

	calendar : null,

	id : 'date-calendar', 

	container : 'date-calendar-container',

	activeInput : null,

	initialize : function() {
		var icons = YAHOO.util.Selector.query('.date-icon');
		YAHOO.util.Event.addListener(icons, 'click', this.click, this, true);
		this.renderContainer();
	},

	renderContainer : function() {
		var container = document.createElement('div');
		container.id = this.container;
		container.style.display = 'none';
		document.body.appendChild(container);
	},

	click : function(e) {
		this.activeInput = common.byEvent(e).getAttribute('field');
		if(this.calendar === null) {
			this.renderCalendar();
		}
		this.calendar.show();
		this.positionCalendar();
	},

	renderCalendar : function() {
		this.calendar = new YAHOO.widget.Calendar(this.id, this.container, { title:'Choose a date:', close:true, navigator: true } );
		this.calendar.selectEvent.subscribe(this.populateDateField, this, true);
		this.calendar.render();
	},

	positionCalendar : function() {
		var position = YAHOO.util.Dom.getXY(YAHOO.util.Dom.get(this.activeInput));
		position[1] = position[1] + 25;
		YAHOO.util.Dom.setXY(this.container, position);
	},

	populateDateField : function() {
		var date = this.calendar.getSelectedDates()[0];
		YAHOO.util.Dom.get(this.activeInput).value = date.getMonth() + '/' + date.getDate() + '/' + date.getFullYear();
		this.calendar.hide();
	},

	hide : function() {
		if(this.calendar !== null) {
			this.calendar.hide();
		}
	}

};
YAHOO.util.Event.addListener(window, 'load', DatePickerSingleton.initialize, DatePickerSingleton, true);
</pre></div>
The html for creating this widget is as simple as follows:
<div class="code-highlight"><code>
<label>Date: </label>
<input type="text" id="date_field" />
<img src="images/calendar.png" class="date-icon" field="date_field" />

Results

After testing out each of these approaches using a range from 1 to 1000 inputs on a page, I noticed some interesting side effects. Both approaches load using almost the same amount of resources. You might think the Prototype approach would require more memory on page load to create each of the widgets for each input, but in reality, due to the prototype definition, the only additional memory needed for each widget is for the unique element id’s stored as attributes. Each approach also uses a ‘lazy loading’ approach, that causes the Calendar widget to not be created until the user actually clicks on an icon. This is where the two approaches begin to differ.

The Singleton approach consumes a small amount of additional memory on the first click, as it creates the Calendar widget at this time. For subsequent clicks the memory stays the same, as the objects have already been created, and are just being re-used. A downside to this approach is that on page load, a javascript css selector query has to be executed to gather all date picker icons to set up click events for them. This ‘can’ be time consuming with a large number of elements (1000+).

The Prototype approach will consume additional memory for each new icon that is clicked, as there is a Calendar widget created lazily for each input at the runtime click event of the icon. From my simple tests, I saw an increase ranging from 51.2 kb to 358.4 kb for each additional widget instantiated (each new icon clicked). In contrast to the Singleton approach, on page load there is no css selector query to run in order to attach the click events, as the element ids are already in memory from the instantiation of each ‘wrapper’ (DatePicker) object. This saves the possibly heavy css based query, but adds an initialize function for each input to the page load, which can be time consuming as well.

Recently I have been using the Singleton approach for creating widgets where it is possible, as I believe it scales better, and avoids the problem of memory increasing as users go about using the application. This can be accentuated even further when page life cycle is long such as in the case of single page web applications. I found this little exercise interesting in my own work, and hope it is informative for some other people out there. I’d love to hear any comments regarding this from everyone out there.

var columnCalc1 = slikcalc.create('column', {
	total: { id: 'cc-1-total' },
	registerListeners: true,
	calcOnLoad: true
});

as opposed to:

var columnCalc1 = new slikcalc.ColumnCalc({
	total: { id: 'cc-1-total' },
	registerListeners: true,
	calcOnLoad: true
});

Its a small change, but I think is easier to use. Of course the old way will still work, so existing code will not break with the addition to the API. Some other additions include a new fully commented debug version of the code, along with using YUI compressor for the minified version, which shaved off a few kb from previous versions. Full documentation is also included in the download. Take a look and feel free to comment with any feedback.

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.

• 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)