Last week, we attended AjaxWorld in San Jose and chatted with developers about some amazing innovations happening within the Ajax community. Beyond their experiences with Ajax, we wanted to uncover developers’ opinions about the hottest trends in web app development and also their worst coding nightmares. In the spirit of Halloween, we compiled our findings into some fun (and spooky) videos.

In these videos, find out what developers really think about the wonders and downfalls of IE6, hear scary tales of back end integration gone bad, and get a glimpse of a terrifying world without client/server architecture. But don’t be too frightened. Jeff and Nolan, our fearless leaders, also discuss how Appcelerator is solving some of the toughest problems of application development. And you’ll just have to watch the videos to find out everything you ever wanted to know about Barack Obama, John McCain, and their relationship to open web technologies.

Popularity: 8% [?]

What’s the problem?

Just implementing resource bundles to localize your application doesn’t quite cut it. You need to do things like work with localized dates in the browser (including formatting), numbers, currencies, and who knows what else to munge your data. It sure would be nice if there were a way to transparently make this happen in a message oriented way that does not require server side awareness for services, can you help me with this problem? sure.

Built in ‘ization’ support in Appcelerator

Globalization (G11N) and Localization (L10N) both get lumped into Internationalization (I18N) - how to deal with languages, time, data formats and everything else that goes on making it so that people in different places in the world can use your glorious application. Appcelerator localization helps you out with this on some really simple levels with the langid attribute:

  <span langid="account.number.title"></span>:<input type="text"></input>

This should arm you successfully with an ability to deal with things like simple messages and labeling in your application. Now if you want to blend in your data payload to render localized text, you can make use of appcelerator javascript functions Appcelerator.Localization.get and the more powerful but less documented Appcelerator.Localization.getWithFormat.

<script>
  var en_lang_bundle = {
	"invalidlogin.message": 
"Dear sir/madame, the username you provided '#{username}' does not exist:"
  }
  Appcelerator.Localization.addLanguageBundle("en",English",$H(en_lang_bundle));
</script>
<span on="l:invalidlogin.response then value[text]"></span>
<app:script on="r:invalidlogin.response then execute">
  var text = Appcelerator.Localization.getWithFormat('invalidlogin.message',
null,null,{username:'azuercher'});
  $MQ('l:invalidlogin.response',{text:text});
</app:script>

This is a nice way to use message indirection for munging messages, but really is quite messy and anything but transparent. There must be a better way!

Interceptors

A lesser known feature of Appcelerator is the concept of interceptors - client side behavior that you can have play in-between the delivery of queued messages to their recipients. In the case for client-2-server orchestration all server requests and their corresponding response messages are enqueued and subject to perversion by interceptors. You just have to know how to implement them. Lets say that whenever I send a CRUD request to the server called ‘r:createorder.request’ I want to add a new attribute called last_modified_utc which is a numerical representation of a utc date as a long. I can add that to the payload to the back end service completely transparently with the Appcelerator.Util.ServiceBroker.addInterceptor method - the method takes a callback to the following:

• interceptQueue - where requests from client to server are intercepted
• interceptSendToListener - where responses from server to client are intercepted

In the example below I

• add ‘last_modified_utc’ as a current utc long to r:createorder.request which is consumed by my back end service
• transform ‘last_modified_utc’ in the r:createorder.response from utc to a localized string in the browser

<app:script>
	var interceptor = {
	    interceptQueue: function(msg, callback, messageType, scope) {
			if (messageType=='remote:createorder.request') {
				msg.data.last_modified_utc = new Date().getTime();
			}
	        return true;
	    },
	    interceptDispatch: function (requestid, type, data, datatype) {
	        return true;
	    },
	    interceptSendToListener: function (listener, messageType, data, datatype) {
			if (messageType=='createorder.response') {
				date = new Date(data.last_modified_utc);
				data.last_modified = date.toString();
			}
	        return true;
	    }
	};
	Appcelerator.Util.ServiceBroker.addInterceptor(interceptor);
	$MQ('r:createorder.request',{hi:'there'});
</app:script>

Obviously, you can take this a step further and then add interceptors that munge your data conditionally based on the current locale defined in Appcelerator.Localization. The benefit here is that this data transformation happens at a layer outside of my normal pub/sub for messages in Appcelerator - the normal pattern is to either replace or add attributes in the payload.

wrap up

Although not a shrink wrapped solution for I18N in all its glory, its not hard to implement interceptors to do so. Beyond I18N, a lot of other aspects for your messages can be mutated in the browser non-intrusively. Although the key demonstration here is data transformation, you would potentially add other horizontal services into your application.

this article cross-posted at http://blog.zuerchtech.com/2008/10/13/using-appcelerator-interceptors-for-i18n-l10n-g11n

Popularity: 7% [?]

It’s not fully ready for prime time yet but it should come together in the next few days. However, if you’d like to start following the dev, hop on over to GitHub and check out TestMonkey.

TestMonkey is an open source (Apache License) UI test framework we’re introducing today. It’s going to be fully integrated into Appcelerator (with some additional cool features on top if you’re using in an Appcelerator app). Additionally, it’s completely standalone as well and you can use on any web application - appcelerator-based or not.

Our main goal is to create a better UI framework for building out front-end test cases. We’re initially focused on unit tests. However, we’ll introduce higher level testing like use case testing soon. We’re going to offer some really neat features in the coming months to do much more advanced automated testing and quality control. So, stay tuned!

There’s a lot of great frameworks for testing out there. But, in open source style, we’ve continued to experience a lot of difficulty trying to do it with everything we’ve found so we’re going to introduce our own product. I’ll talk more in an upcoming post as we get closer to an official release about some of the differences and why we think our approach is easier, faster and ultimately, better.

Here’s some cool things you can do today with it:

1. All test suites run inside their own iframe sandbox. so, if you have any weird issues in one test suite or set of specific tests, you won’t screw up the others…

2. We’re providing a lot of convenience assertions for common UI testing .. thinks like checking for element attributes, element values, checkbox states, etc. are all as easy as pie.

3. We’re building a super cool UI on top for driving tests and the reporting of tests. Right now it’s pretty limited but we’re going to blow that out. Our goal is to provide as much information about failures, location of failures, expected results, etc. so it’s easy to figure out the issues.

4. TestMonkey has a clean API and can easily be extended, for example, to create your own assertion helper functions or test monkey plugin for handling results. In fact, our UI driver is simply an implementation of this plugin. You can easily hook into your own system if you’d like to handle results or do interesting things with them.

5. TestMonkey itself is very small and you don’t need to include anything in your application related to it. Test monkey can load your HTML files up in the sandbox and then your tests can run against the real source, no crazy includes or manually adding of test framework into the real app. It cleanly separates your tests from the real app.

And, there’s more…. And a lot more planned.

From an Appcelerator perspective, we’re essentially re-writing all our unit tests for the entire front-end in Test Monkey now for the upcoming 3.0 release. This will make it much faster to run through all the UI tests across multiple browsers and platforms. Our current web unit test framework is very manually intensive and takes about an hour to run (by a person, not a computer) for each browser + platform combo. With TestMonkey, we’ll be able to run around 90% of the unit tests on an automated basis across multiple platform concurrently. We’re also going to add this to our nightly build as well as continuous build system in the near future. This should really improve the speed and quality of the product.

(NOTE: this is a cross-post from my personal blog as well).

Popularity: 6% [?]