JSON

Putting the Google Base API to Good Use - Part 1

Tagged:  

A while back I wrote a post about creating a Product search using the Google Base API. We'll I've made a few examples for another blog that I've been writing on called The Porsche Guy's.

Since the blog focuses on Porsche related news and projects (I happen to have an older Porsche 944, so enjoy talking about the cars) I created two Porsche related searching tools. The first is a Porsche Parts finder that makes it easy to find the best prices on the Web for Porsche parts (you can go to the Porsche Parts Finder here). The second is a Porsche Finder, so it you are looking for a good deal on a Porsche then this tool will find the best on the web (You can see the Porsche Finder here).

My next post will go into detail as to how exactly I created these searching tools including code snippets, so look for part 2 of this post. Until then check out my first post about creating a Google Product Based Search Application here.

How to Make a Search Based on Google's Product Search

You may have seen the Google Product Search and may have thought that it would be useful to include a customized version of the search into a website or application. Unfortunately, you can't just create a custom search engine based on the Product Search using Google's custom search creator.

So, how would you incorporate the Product Search into an application? The answer is to use the Google Base API. The API allows for you to call a feed and if you use the [item type:products] option it will use the Product Search data.

The API allows you to receive the feed in Atom, RSS and JSON formats. Google has also made it very easy by making a feed URL builder (you can access the builder here).

So, if you want to make an application using the Products Search now you can.

ECMAScript 3.1 Final Draft Emerges

Tagged:  

Also known as ECMAScript 5th Edition, the new JavaScript standard has entered final draft stage. Among the goodies: a formal getter and setter syntax for object properties, language reflection features, support for the JSON data format, additional Array methods, and a strict mode that improves error checking.

Function.bind

Function.prototype.bind(self, args...). A bind function wraps a function in a closure, storing references to the context arguments from the surrounding scope. This is somewhat equivalent to the following:

Function.prototype.bind = function(context) {
  var fun = this;
  return function(){
    return fun.apply(context, arguments);
  };
};

Applications include partial application of arguments to a function and currying. Though you can custom-roll one today, a native bind function in 3.1 should outperform any equivalent user-defined function.

Array

The additional Array methods in ECMAScript 3.1 are identical to methods introduced in JavaScript 1.6-1.8, but were never present in any official ECMAScript specification. They are currently implemented in Firefox 3.x. Of course, having them in ECMAScript 3.1 means that now you will be able to actually use them (provided, of course, that all browsers implement the standard...). These methods are: indexOf, lastIndexOf, filter, forEach, every, map, some, reduce, and reduceRight. There's a good description of each method here.

ECMAScript 3.1, also known as JavaScript Harmony, is the less ambitious version of what was to be JavaScript 2/ECMAScript 4, a plan scuttled when some members of ECMA balked at the large additions to the language.

The new specification is available here.

JSON - 3D Proof of Concept

A few weeks ago I wrote a post on the concept of using JSON for creating 3-D models (You can read the first JSON 3D post here). I have created a proof of concept based on MooCanvas to allow for IE support. This proof of concept is also based on the 3D cube demo for MooCanvas with some modifications.

For this proof of concept the important function is Load3D which loads and translates the JSON 3D object.

 		function Load3D(obj, translateX, translateY, translateZ){
			scene.shapes[(obj.type + ObjectCounter + "")] = new Shape();
			var p = scene.shapes[(obj.type + ObjectCounter + "")].points; // for convenience
			for(var a=0; a<obj.vrt.length; a++){
				p[a] = new Point(((obj.vrt[a][0])+translateX), ((obj.vrt[a][1])+translateY), ((obj.vrt[a][2])+translateZ));
			}
 
			// Create Shape From Points
			for(var a=0; a<obj.fac.length; a++){
					scene.shapes[(obj.type + ObjectCounter + "")].polygons.push(new Polygon(
					[ p[obj.fac[a][0]], p[obj.fac[a][1]], p[obj.fac[a][2]], p[obj.fac[a][3]] ],
					new Point(obj.nrm[a][0], obj.nrm[a][1], obj.nrm[a][2]),
					true /* double-sided */,
					Polygon.SOLID,
					[obj.mat[a][0], obj.mat[a][1], obj.mat[a][2]]
				));

			}
			ObjectCounter+=1;
 		}

For the JSON 3D object you would pass it into the Load3D function. While in this example I have put the JSON 3D object in the HTML, you would load the JSON 3D using Ajax (or a script tag) in the real world.

			var ThreeDobj = {
			"vrt":[[-10,-10,-10],[10,-10,-10],[10,10,-10],[-10,10,-10],[-10,-10,10],[10,-10,10],[10,10,10],[-10,10,10]],
			"fac":[[0,1,2,3],[4,5,6,7],[2,3,7,6],[2,3,7,6],[0,4,7,3],[1,5,6,2]],
			"nrm":[[0,0,-1],[0,0,1],[0,1,0],[0,1,0],[-1,0,0],[1,0,0]],
			"mat":[[70,70,70],[80,80,80],[80,80,80],[75,75,75],[70,70,70],[70,70,70]],
			"type":"cube"}
			Load3D(ThreeDobj, 0, 0, 0);

You can see the proof of concept here.

The proof of concept has been tested on Google Chrome, FireFox 3 and IE 7. It may work on other browsers (it should work on Safari and Opera), but has not been tested.

JSON - 3D

Tagged:  

Recently I have been looking at 3D as it pertains to the web and controlled through JavaScript without the aid of plug-ins (this is a topic that interests me as in my early programming I created a lot of 3D applications). While Canvas is currently good for 2D rendering (on most browsers and IE with a little help from Google) we are still a ways off from cross browser Canvas 3D support. While I have found a few 3D engines written with Canvas, they all seem to bomb on IE (even with Google's IE Canvas script).

Even if a good 3D solution was available for the web we still have the issue of being able to load all the models for a scene. This got me thinking a bit about how the loading of scene information could be made to work on the Web.

The concept that I have come up with is fairly simply. You would load a map of the scene (this map may could be stored in JSON and could be made to work as a BSP [Binary Space Partitioning] tree) and on the map you would have various check points. Each checkpoint would load the needed models using JSON.

Below is an example of what the JSON for a cube may look like.

{"obj":[{"vrt":[[-5,-5,5],[5,-5,5],[-5,5,5],[5,5,5],[-5,-5,-5],[5,-5,-5],[-5,5,-5],[5,5,-5]],"fac":[[0,2,3,1],[3,1,0,1],[4,5,7,0],[7,6,4,0],[0,1,5,4],[5,4,0,4],[1,3,7,3],[7,5,1,3],[3,2,6,5],[6,7,3,5],[2,0,4,2],[4,6,2,2]],"nrm":[[0,0,-1],[0,0,-1],[0,-0,1],[-0,0,1],[0,-1,0],[0,-1,0],[1,0,-0],[1,-0,0],[0,1,0],[0,1,0],[-1,0,0],[-1,-0,-0]]}],"mat":[{"r":150,"g":225,"b":219},{"r":150,"g":162,"b":223}]

While this is just a concept and we are still waiting on the technology to make the possible. It is interesting to think of how we may be able to use JSON - 3D in the near future.

You can see a demo of Canvas 3D by nihilogic.dk using JSON for models here (this works on Firefox, but may not work on other browsers).

Accessing JSON Web Services with the Google Web Toolkit

Over at GWT Site they have written a good post about using the Google Web Toolkit with JSON Web Services. Since JSON is fast becoming a standard for web services that are cross domain and GWT is a heavily used development tool this is a useful post.

below is an excerpt from the post.

The main difficulty when trying to talk to some web service on another server is getting past your web browser’s Same-Origin Policy. This basically says that you may only make calls to the same domain as the page you are on. This is good for security reasons, but inconvenient for you as a developer as it eliminates the use of GWT’s HTTP library functions to achieve what we want to do. One way to get around this is to call a web service through a javascript <script> tag which bypasses this problem. In his book, Google Web Toolkit Applications, Ryan Dewsbury actually explains this technique in more detail and provides a class called JSONRequest which handles all the hard work for us. JSON is one of the more popular data formats, so most web services support it. Lets leverage Ryan’s code and take a quick look at how it works.

public class JSONRequest {
  public static void get(String url, JSONRequestHandler handler) {
    String callbackName = "JSONCallback"+handler.hashCode();
    get( url+callbackName, callbackName, handler );
  }	
  public static void get(String url, String callbackName, JSONRequestHandler handler ) {
    createCallbackFunction( handler, callbackName );
    addScript(url);
  }
  public static native void addScript(String url) /*-{
    var scr = document.createElement("script");
    scr.setAttribute("language", "JavaScript");
    scr.setAttribute("src", url);
    document.getElementsByTagName("body")[0].appendChild(scr);
  }-*/;
  private native static void createCallbackFunction( JSONRequestHandler obj, String callbackName)/*-{
    tmpcallback = function(j) {
      obj.@com.gwtsite.client.util.JSONRequestHandler::onRequestComplete(Lcom/google/gwt/core/client/JavaScriptObject;)(j);
    };
    eval( "window." + callbackName + "=tmpcallback" );
  }-*/;
}

To make our request we call the get method with the web service url, and an implementation of the JSONRequestHandler interface. This interface has one method called onRequestComplete(String json). This is where you’ll handle the JSON formatted data once it comes back from the server. When calling a service from within a script tag, we need to specify the name of a callback function in the request. Most services let you specify the name yourself, so the first get method generates a callback name for you. The createCallback method is a JSNI method that simply calls your JSONRequestHandler implementation when the call returns via the callback name. Note, if you use this class, to make sure and change the package name for the JSONRequestHandler call to the correct location. Finally, the get method will call the addScript function which is responsible for embedding the <script> tag on your page and setting its src attribute to the web service url.

You can read the full post here.

Since I am a fan of both JSON and GWT I enjoy seeing good posts about using these two technologies. I recommend this post for any Java developer that wants to make Ajax applications using Web Services.

The Future of JSON

Tagged:  

I am a huge supporter of JSON as a means of communicating with the server side in an Ajax application (you can use JSON as a means of communication on all tiers of an application using a library, but I'm going to mainly focus on the client side for this post). I was looking into the future of JSON and found two great posts by John Resig.

The first is about the need for native JSON support.

The post goes into a lot of detail about the performance benefits of JSON and has some great code samples.

Below is the summery excerpt from the post.

The current, recommended, implementation of JSON parsing and serialization is harmful and slow. Additionally, upcoming standards imply that a native JSON (de-)serializer already exists. Therefore, browsers should be seriously looking at defining a standard for native JSON support, and upon completion implement it quickly and broadly.

To get the ball rolling, I recommend that you vote up the Mozilla ticket on the implementation, to try and get some critical eyes looking at this feature, making sure that it's completely examined and thought through; and included in a browser as soon as possible.

You can read the full post here.

The second post is about the current state of JSON and goes into detail about ECMAScript proposals for the API.

Below is an excerpt from the post about the Mozilla implementation of native JSON.

Mozilla Implements Native JSON - Mozilla was the first to implement native JSON support within it's browser. Note, however, that this is not a web-page-accessible API but an API that's usable from within the browser (and by extensions) itself. This was the first step needed to implement the API for further use.

Here is an example of it in use (works within an extension, for example):

var nativeJSON = Components.classes["@mozilla.org/dom/json;1"]
    .createInstance(Components.interfaces.nsIJSON);
nativeJSON.encode({name: "John", location: "Boston"});
// => '{"name":"John","location":"Boston"}'
nativeJSON.decode('{"name":"John","location":"Boston"}');
// => {name: "John", location: "Boston"} 

You can read the full post here.

Hopefully the future will have native support for JSON. As usual John does a great job on the post and if you don't have John's blog on your feed reader I recommend adding it (he is a very good Ajax development reference).

Why XML is far superior to JSON

Tagged:  

I've read an article titled Does XML have a future on the web?, and it does not surprise me, because the author himself is the creator of JSON. Naturally, he would love to promote his stuff. I would like to ignore him but would like to address his questions.

Lets see what he got.

"For data transfer applications, XML is losing ground to JSON because JSON is simply a better data transfer format".
I want to know how? Everyone in the world knows XML is more recognized and widely used and it is well supported by every one of the vendors in the web world (Editors, Application Servers, Parsers, Web Servers, Loaders etc.). JSON's role is what? Simply converting raw text in to a JavaScript object. And how is that a better data transfer format? Can I take the same raw text and use it else where? I don't think so.

I heard there are some frameworks available for JSLT (yeah you heard it right, JavaScript - SLT) available as open source, still I would challenge the performance about those frameworks. I haven't tried them myself, but you cannot beat the performance provided by the native browser XSLTs. I could reuse same XML data and apply different XSLTs to get different sets of transformed structures. You can't even think about this using JSON. And that to you can transform using XSLT's in milliseconds. With JavaScript JSON, you'll be lucky if you can get it in seconds.

Also, what about reusability? My server still can send the same XML and I could put a SOAP wrapper on top of that and I could expose it to web services. Now anybody can invoke that web service. Not necessarily only on the web side, it could be invoked by any server side programs as well. XML is the de-facto standard for Data integration projects, Data warehousing projects. More and more corporations are moving towards a SOA (Service oriented architecture) model and more and more applications have to use XML as the data transport mechanism.

JSON may be used by applications which are not enterprise level, only for applications which deal with less data, and have no need for extensibility. But for more scalability, more robustness, and more extensibility, XML is your best bet. XML has more support and that's what your boss would like to hear.

Get Insight into Digg's Bury System with Ajaxonomy's Bury Recorder

Tagged:  

If you have been using the popular service Digg you know that it is very easy to submit a story and to see it start to gain traction just to be buried into the dark abyss. What I find particularly frustrating is that you don't know how many people buried the story and the reason for the bury. If you have seen Digg Spy you have noticed that the application does show buries, but you can't just track data for a particular story.

After much frustration Ajaxonomy is now releasing a Bury Recorder application. How the application works is you take the story's URL (This is the URL of the page that the "more" link on the Digg upcoming/popular pages takes you or the page that clicking on the story title takes from your profile i.e. http://digg.com/[story]) and put it into the application and once you click "Watch for Buries" the application will start recording any buries that the story receives. This will allow you to see if your story had 100 diggs and 5 buries before it was permanently buried, or if it was more like 100 diggs and 300 buries. The idea is that you would submit a story and then have the recorder capture any buries from the time that you start the application watching for buries. You'll want to note that in this Beta 1.0 release, so currently you have to leave your machine on and the application open in order to make sure that it continues to capture buries.

Before I go a bit into the design and more information on using the application I wanted to say that the application is open source and can be changed and put on your server. If you do change it and/or put it on a different server then we just ask for a link back to us and credit us for the initial creation of the application. Also, if you do decide to put it on a server, let us know and we might link to your server as another option to elevate traffic concerns on our server.

So, now that I have you are excited you will want the link to the application. Click here to be taken to Bury Counter Application.

The following is a quick overview on how to use the application so that it will make it a bit less confusing to use (more than likely most people could figure it out, but this way if it looks like it isn't working you have somewhere to look).

Using the application is as easy as one two three, however there are two ways to use the application below is the first way of using the application.

  1. Open the application (once again the link to the application is here)
  2. Copy and paste the URL of the story into the text box (i.e. http://digg.com/[story])
  3. Click the "Watch for Buries" button and then let the application start recoding buries (make sure not to close the application or to turn off/hibernate your computer)

The other way to use the application is as easy as one two (yep, there is no three using this method). Before using the below steps you will need to create a bookmarklet which can be done by following the directions at the bottom of the application.

  1. Click on the bookmarklet from the story page on Digg (this has to be the page that you get when you click on the "more" link in Digg [or from your profile page it would be the page that clicking on the title of the story takes you] which is the page that you would use to get the URL for the first method)
  2. Click the "Watch for Buries" button and then let the application start recoding buries (make sure not to close the application or to turn off/hibernate your computer)

Now that you know how to use the application I will go a bit into how the application was created. This application gets the JSON Feed used by Digg Spy. It does this using Ajax (i.e. the XMLHTTPRequest object) which requires a server side proxy due to domain security restrictions. Due to the way that the JSON is returned from Digg Spy, it doesn't set a variable equal to the returned object, which force us to use the before mentioned server side proxy and an eval statement instead of using DOM manipulation. The application simply polls for updated data every 20 seconds which makes sure we don't miss any data and that it doesn't put too much strain on the server.

You can download the full source code for this Beta 1.0 release here.

This release has been tested in Firefox 2.0.0.11 and Internet Explorer 7. It should work in many more browsers, but has not yet been tested. If you try it in a different browser and either find bugs or the application works perfectly then we would appreciate if you contact us regarding your testing results.

Also, if you do any cool things with the application or if you have any cool ideas then feel free to blog about it on this blog. Just sign up for a free account and once you login click on "Create Content" => "Blog Entry" and then write your post. If the admins of this site feel that your post is an interesting one they will move it to the home page.

I hope that you find this application useful and that you keep checking for new version and improvements.

Object Oriented JavaScript - Should You Use It? - Part 2

This is the continuation of a post that I wrote yesterday (click here to read the original post). This post will go into much more depth and will be a bit more technical.

Now to begin to answer the question of should you use object oriented JavaScript (don't worry I will touch on the fact that we have all already used JavaScript objects). The first thing that we should understand is how it is used and what are the advantages or disadvantages. If you have been programming in a language like C++ or Java then you are use to a class style of object oriented. JavaScript does not use this structure, instead an object in JavaScript is based on functions and properties.

JavaScript object oriented programming can be noted in different styles.

The first type of notation is to use the new operator along with the Object() method.

person = new Object()
person.name = "John Doe"
person.height = "6Ft"

person.run = function() {
	this.state = "running"
	this.speed = "4ms^-1"
}

In the above code we define an object named person and then add it's own properties. Also the property person.run will execute the function.

The next notation will be familiar if you have ever used JSON. The below notation is referred to as literal notation. This notation simplifies things a bit and this is much better for sending over the web in an Ajax application where such things really matter.

var rectangle = { 
	upperLeft : { x : 2, y : 2 },
	lowerRight : { x : 4, y : 4},
	method1 : function(){alert("Method had been called" + this.upperLeft.x)}
};

The shortcoming with this method is that it does not lend as well to re-usability.

So far you are probably thinking that this is a waste of time and that why would I ever use this, outside of JSON. Well, now we will start to see the power of this coding style which is in re-usability.

The below example will create an object and will set the value of the name property.

function cat(name) {
	this.name = name;
	this.talk = function() {
		alert( this.name + " say meeow!" )
	}
} 

cat1 = new cat("felix")
cat1.talk() //alerts "felix says meeow!"

cat2 = new cat("ginger")

The above code shows how you can easily create multiple objects based on the same object. Which brings me to how you have already used object oriented JavaScript. For example the document.getElementById() method is an example of an object that you more than likely have used (don't worry Prototype library lovers, I'll touch on $() in just a moment).

One of the great things with objects is that using prototype (if you have been programming in ActionScript you will be familiar with the below) you can now extend the functionality of an existing object in a new object.

The below code is an example of how to use prototype to extend an object.

cat.prototype.changeName = function(name) {
	this.name = name;
}

firstCat = new cat("pursur")
firstCat.changeName("Bill")
firstCat.talk() //alerts "Bill says meeow!"

Using prototype you can extend existing JavaScript objects, such as the date (I believe that this is how the prototype library creates the $() method which is in essence the document.getElementById() method) object.

The below example shows how to extend array object with the shift and unshift methods that are not available in some browsers.

if(!Array.prototype.shift) { // if this method does not exist..

	Array.prototype.shift = function(){
		firstElement = this[0];
		this.reverse();
		this.length = Math.max(this.length-1,0);
		this.reverse();
		return firstElement;
	}
	
}

if(!Array.prototype.unshift) { // if this method does not exist..
	
	Array.prototype.unshift = function(){
		this.reverse();
		
			for(var i=arguments.length-1;i>=0;i--){
				this[this.length]=arguments[i]
			}
			
		this.reverse();
		return this.length
	}
}

If you have been programming in a language link C++ or Java you are probably very familiar with a class structure. Part of this is the idea of a class and a subclass. While most JavaScript object oriented code will not use the following, below is an example of how you can create classes and subclasses in JavaScript.

function superClass() {
  this.supertest = superTest; //attach method superTest
}

function subClass() {
  this.inheritFrom = superClass;
  this.inheritFrom();
  this.subtest = subTest; //attach method subTest
}

function superTest() {
  return "superTest";
}
  
function subTest() {
  return "subTest";
}


 var newClass = new subClass();

  alert(newClass.subtest()); // yields "subTest"
  alert(newClass.supertest()); // yields "superTest"

So, now that you have seen how you can extend and reuse JavaScript objects it still leaves us with the question of should you use it. If you need to create code that needs to be reused or extended then it should be a JavaScript object. If you are just writing code that does a few lines of code that doesn't need to be reused or extended then procedural (a.k.a. typical function style code) style code is fine to use. So, the answer to the question is yes in many cases although there are times when it may be overkill.

The next post will take a look at how JavaScript will soon be changing once (or some would say if) ECMAScript 4 starts getting major browser support.

So, as always if you have any questions leave a comment or you can private message me once you add me to your buddy list (I will add you as a buddy as soon as I see the request) that is available once you login. Also, if you would like to write anything on this blog you can do so once you login by clicking on create content and then blog entry. The most interesting posts will be promoted to the home page.

many of the above code samples where taken from this post on JavaScript Kit.

Syndicate content