Author Archives: John Bracy

YUI3 Lets You Call Webservices With No Server Required

I like YUI3, mostly because I can use it to fill in the gaps between HTML4 and HTML5, and also because a single line of code can make a button zoom around the page:

  var myAnim = new YAHOO.util.Anim('testButton', 
                      { width: { to: 400 }  }, 

Also, I can define data sources and polling intervals completely client side, without having to wait for everyone to finish implementing the event-source tag. YUI3 defines 3 useful objects: DataSource, DataSchema, and DataType. DataSource defines a generic source of data. It could be a function, a file, or a web service. Once the DataSource has been configured, you can pull from and publish to the specified location. Here’s a simple example:

YUI().use("datasource-function", function(Y) {
   var getDate = function() {
     return new Date();
   dateDataSource = new Y.DataSource.Function({source:getDate}),
   callback = {
      success: function(e){
                  alert("Current Time is: " + e.response.results[0]);
      failure: function(e){
                  alert("Error!: " + e.error.message);
    dateDataSource.request(null, callback);

Above, we’ve got some basic YUI steps. The first line defines a block of YUI code that depends on the datasource-function component. In the block, we define a method to get the current date and time, and a DataSource the pulls its information from that function. Next up, we define a callback to handle the possible return situations when the data source requests information. The last line requests data from the function.

YUI will call the getDate function, take the output from that function and pass it as an event to the callback. If there was no problem, the browser will pop up a window telling you what time it is.

Enough of that, let’s turn it up to 11. We will change up the data source to pull from a webservice first:

   stockDataSource = 
            new Y.DataSource.Get({source:""},

The Get data source knows to look for a URL. We’ll pretend this one will give us the NASDAQ index number. We will also pretend that the response looks like this:


So, now we need to define the schema for the data source. Simple enough, we just need to plug in a schema definition:

  stockDataSource.plug({fn: Y.Plugin.DataSourceXMLSchema, cfg: {
     schema: {
          resultListLocator: "stocks",
          resultFields: [{key:"value"}]

Above, we’ve defined the resultListLocator to the be xpath to a list of results, in this case stock nodes. Then we specify the fields of that we’re interested in, namely the value node. The DataSchema will be applied to all data coming into the data source. Now, we just modify the callback handler to deal with the new information, like so:

   callback = {
        function(e) {
          alert("The NASDAQ Index is currently: " + e.response.results[0].value);

The response contains an array results, which is a list of objects exposing the resultFields as properties. And now when stockDataSource.sendRequest(null, callback); is executed, the DataSource will consume the webservice, format the XML into an array of objects, attach them to the response event and pass it on to the callback function. No server handling required.

Agile Conversations

Everyone, especially project managers, is in love with Agile Development. And why wouldn’t they be? Under the old school system, you’d end up with developers either sitting around uselessly, or drafting up prototypes that will only be thrown away. Agile allows for parallel design and development, wasting less time and money. But there’s always a tradeoff. In this case, I’m thinking of commonality of design. Let me explain by example:

I’m currently working an Agile project with three developers including myself. We’ve divied up the tasks so that one is doing the JSF database plumbing, and the other two are creating the web services that sit on the back end. We started development without having a certain idea of certain database keys, so we naturally wrapped the keys in an object that we could easily change when the decision was made. It let us move forward with development and had a very low cost for change when business came back with a decision. But we each implemented it in a difference way, using a different nomenclature and at different times. So now we have three objects that perform identical tasks, and require a translation process when our respective parts interact with each other. It’s not broken, but it’s definitely messy.

And it’s a natural fallout of the tendency to think that Agile means you start developing right away, and things like requirements and interfaces can be laid on top of the code later. How do we prevent it? Sadly, communication is the only answer. Code reviews early on could have prevented this situation before it would have been a pain in the tuckus to refactor. A project wiki exists, and even has a section that lays out common objects and interfaces. But the wiki was infrequently referenced for matters of actual code implementation; it was for the documents and the Agile storyboards.

In the end, it’s important to recognize that Agile development has taken the large chunk of communication out of the beginning phase of a project. But that communication isn’t gone, it’s been spread out over the duration of the project, and in most cases that means there going to be a lot more of it. As developers we eagerly embrace Agile projects since it means we don’t spend two months in design meetings and can’t indulge our love of code early on, but we have to realize that it comes with a cost. We actually have to talk to each other.