Archive

Archive for the ‘JavaScript’ Category

The Same Origin Policy: JSONP vs The document.domain Property

March 18th, 2010

The Same Origin Policy ensures that the client-side code (JavaScript) running on a website originated from that website. This prevents website http://kahtava.com from accessing resources (via client-side code) on website http://malicious-password-sniffers.com or website http://adam.kahtava.com from executing resources from http://kahtava.com - note that the sub-domains differ, one being kahtava.com, the other being adam.kahtava.com

In most cases The Same Origin Policy is desirable. It helps to prevent malicious code that could potentially reveal sensitive information from being run on arbitrary website. However, the same origin policy also makes it difficult to share resources within a common root domain, or run external widgets on your site (like displaying The Project Badge within your site). There are a couple ways to circumvent The Same Origin Policy, but I focus on JSONP and the document.domain property in this post.

Ways to circumvent the Same Origin Policy

  1. JSONP
  2. Modifying the document.domain property
  3. Creating a server side web proxy

JSONP (JSON with padding)

How it works: JSONP dynamically creates a script element in the head of your HTML document which then requests data from outside your domain. JSONP exploits a loophole in the Same Origin Policy that allows JavaScript from an external sites to be run within your site (much like how web analytic tracking works). The JSON response, when returned, is executed within your browser at which time the JavaScript can manipulate your HTML page / DOM.

An Example Using JSONP with jQuery:

JAVASCRIPT:
  1. (function(){
  2.   $.getJSON('http://adam.kahtava.com/services/open-source/projects.json?project-host:username=github:adamdotcom&callback=?', function(data) {
  3.     alert(data);
  4.   });
  5. })();

Note the callback=? at the end of the URI, in jQuery this indicates a JSONP call.

Pros

  • Lets us make external calls to any endpoint that supports JSONP
  • Lets us make external calls from HTTP to HTTPS
  • Supported by all major browsers

Cons

  • A bit more complex upfront, but most server side technologies support JSONP, browsers are natively supporting JSON, and JavaScript libraries like jQuery continue to abstract away most of the complexity.

The document.domain property

How it works: the document.domain property contains the domain of the server from which the page was loaded. For example, the domain for http://adam.kahtava.com/ would be adam.kahtava.com whereas the domain for http://kahtava.com would be kahtava.com. The Same Origin Policy restricts resource access from kahtava.com to adam.kahtava.com unless we set the document.domain property to the root domain (in this case I'd want it set to kahtava.com to share resources with http://adam.kahtava.com).

An Example using the document.domain property:

JAVASCRIPT:
  1. (function(){
  2.   document.domain = 'kahtava.com';
  3.   $.get('http://adam.kahtava.com/contact-me/', function(data) {
  4.     alert(data);
  5.   });
  6. })();

Pros

  • An easy way to access resources within our root domains
  • Supported by all major browsers

Cons

  • Prevents us from making external calls outside a root domain
  • Prevents us from switching between HTTP and HTTPS
  • Kind of a hack - technically, the document.domain property is supposed to be a read only property, but most browsers also provide set access

JSONP vs document.domain isn't a cut and dry comparison. JSONP lets anyone consume and share data, whereas overriding the document.domain lets you share resources within a common root domain. In simple cases where your only concern is sharing data within a single domain (exclusively on HTTP or exclusively on HTTPS), then overriding the domain works well, but in cases where you want to share or consume external data that may be passed over HTTP or HTTPS you'd probably want to stick with JSONP.

The Project Badge makes use of JSONP so it can work on your website. Most of my publicly available web services also make use of JSONP through a WCF JSONPBehavior.

The Project Badge: Show The World Your GitHub and Google Code Projects On Your Blog

February 24th, 2010

The Project Badge displays your GitHub and Google Code projects in a badge that can be displayed on your site. This widget was built on the data being returned from my Open Source Service.

View this post outside your RSS reader to see it in action or view it here.

The source for the Project Badge can be found here and the source for the accompanying service can be found here. A list of all my publicly available web services can be found here.

Using The Project Badge On Your Website or Blog

1. Add The Asset References

Add the following asset references, and a reference to jQuery (if you don't have one already).

HTML:
  1. <link rel="stylesheet" type="text/css" href="http://github.com/AdamDotCom/project-badge/raw/master/project-badge.css" />
  2. <script type="text/javascript" src="http://github.com/AdamDotCom/project-badge/raw/master/projectBadge.js"></script>

2. Configure Your Accounts

Set your project accounts (it's OK if you only use one host) then optionally set the appropriate filters - in my case my Google Code projects were prefixed with adamdotcom and I had duplicate projects on both GitHub and Google Code. By specifying remove:adamdotcom,remove:duplicate-items in my filters I filter out the duplicates and removed adamdotcom from the project name.

JavaScript:
  1. <script type="text/javascript">
  2.   projectBadge.load({
  3.       gitHub: 'AdamDotCom',
  4.       googleCode: 'adam.kahtava.com'
  5.     },{
  6.       filters: 'remove:adamdotcom,duplicate-items,-,empty-items'
  7.     });
  8. </script>

3. Add The Widget Hook
Add an element to your site or blog with the id of project-badge.

HTML:
  1. <div id="project-badge">
  2.   Loading...
  3. </div>

That's it!
If you have any issues, use the the working example as a reference, or send me a message.

Free: Win a Copy of: JavaScript: The Definitive Guide by David Flanagan

July 23rd, 2009

Free to a good home: JavaScript: The Definitive Guide by David Flanagan.

It's rare for technical books to be held in such high esteem, but the numbers speak - this book has close to 200 five star ratings on Amazon, confirming that The Definitive Guide is still one of the seminal guides to the JavaScript language. Flanagan's book is a must read for developers and designers alike. Along with JavaScript: The Good Parts by Douglas Crockford of course. I reviewed this book a while back, you can read my review.

The Details:

  • Comment on this post
  • Leave a valid email in the email comment field
  • The winner will be chosen at random and notified through email on Oct 1st
  • I cross my fingers hoping that you don't live on the other side of the world (I pay for shipping)

Good Luck!

And the winner is Dan Carlson!

Author: Adam Kahtava Categories: Book, Contest, JavaScript Tags:

Book Reviewed: Designing with Web Standards by Jeffrey Zeldman

July 20th, 2009

The title of Jeffrey Zeldman's book (Designing with Web Standards) says it all - this book promoted accessible, usable, search engine friendly web design and development through the use of XHTML and CSS while debunking the myths surrounding web standards. Zeldman is a well recognized name among web developers and designers - he's the the founder of A List Apart, and co-founder of The Web Standards Project (WaSP). His writing is entertaining, witty, easy to read, and insightful - it's very much like the content we're used to reading at A List Apart. It's also fair to mention that this book has been edited by industy experts and influencial writers like Eric Myer. Any developer that works with the web should read this book along with JavaScript: The Good Parts by Douglas Crockford.

Author: Adam Kahtava Categories: Book, CSS, DOM, JavaScript, Review, Web Standards Tags:

Chronic Divitis And Classitis, What Are They?

July 15th, 2009

Jeffery Zeldman offers this entertaining definition for Divitis and Classitis:

Classitis is the measles of markup, obscuring meaning as it adds needless weight to every page. The affliction dates back to the early days of semi-CSS-capable browsers and the many designers' initially childish comprehension of how CSS works.
Alas, many have not yet outgrown that childish misunderstanding of CSS ... Classitis is as bad in its own way as the <font> tag ever was; rarely does good markup require it ... At other times classitis is exacerbated by a still more serious condition ... divitis ... Classitis and divitis are like the needless adjectives with wich bad writing is strewen. They are the weeds in the garden of meaning. - Jeffrey Zeldman, Designing with Web Standards

An example of markup wraught with divitis and classitis:
googleexercise-divitis1
13 div elements and 11 classes for a single item. What a stench! :)  View this markup in action.

The equivalent markup disease free:
googleexercise-semantic
Cleaner, more meaningful, and with all the functionality of the former code. One div element and 3 classes for a single item.  ShamWow! View this markup in action.

Both of these markup snippets are visually and functionally equivalent. In the first example the divs, classes, and cryptic ids weigh down the page and pollute the meaning of the markup. In the later, a more semantic / structural approach is taken  Both these snippets were pulled from my attempts at the Google Web Developer Exercise.

Clean meaningful markup is the API that users and web crawlers consume - it's important and easy to keep things clean, it just takes a little experience. Thank goodness for patterns like MVC.

What Is Semantic / Structural Markup and Why Does It Matter?

July 13th, 2009

I always found the definition of "Semantic / Structural Markup" murky on the intertubes. I thought Jeffrey Zeldman described it well in his book Designing with Web Standards.

What Is Semantic / Structural Markup?

Markup is "semantic" when tags are chosen according to what they mean. For example, tagging a headline h1 because it is the most important headline on the page is a semantic authoring practice. Tagging a headline h1 "to make it look big" is not. ... I use the phrase "structural markup" to mean pretty much the same thing as "semantic markup." ("Structural markup" takes its name specifically from the idea that the web document has an outline-like structure.) - Jeffrey Zeldman, Designing with Web Standards

Zeldman goes on to make many great points on why semantic markup matters, here's my paraphrase.

Why Does Semantic / Structural Markup Matter?

If you're interested in learning more about semantic markup then view A List Apart's source code, or read their many online resources: Topics: Code: HTML and XHTML.

Author: Adam Kahtava Categories: CSS, DOM, JavaScript, Web Standards Tags:

The Google Exercise Revisited: Semantic Markup with jQuery

July 9th, 2009

A couple years ago I tried getting a Web Developer position at Google. After a few interviews they had me complete their Web Developer exercise. I did it, and my initial submission would have made any respectable web developer ill - you can read more here: Getting a Job at Google: A Web Developer Fizzbuzz. I redid the exercise over a year ago, but today even that code stink.

I did the exercise yet again (the third time) because my last attempt needed some improvements:

  • it suffered from chronic classitis and divitis (too many classes, ids, and divs were making me itchy)
  • it wasn't really using semantic / structural markup (all the extra divs etc... cluttered my markup, and some of my class names like container-borders are non-semantic altogether)
  • it performed poorly and wasn't accessible (everything was being rendered in the DOM, there was no immediate rendered markup which kind of violated the idea of unobtrusive JavaScript, nor was it screen reader friendly)
  • it wasn't making use of any JavaScript libraries to abstract browser inconsistencies out of the code
  • it suffered from my software ethnocentrism (my variable and object naming like GoogleExercise was mirroring statically typed languages and not the native language they were being written in)

Here's my latest Google Exercise (addressing all the above concerns):
View this post outside your RSS reader to see it in action or view it here.

This attempt makes use of jQuery and uses 57 lines of JavaScript (almost 200 lines less from my last one).

You can view the code for this attempt here: google.contact.widget.js, index.html, google-contact-widget.css.

You can view the old code here: GoogleExercise.js, index.html, GoogleExercise.css.

If you think I can improve on my code then let me know. Oh yeah, and if you're a recruiter from Google then hire me! :)

Cross Language Naming Conventions: Avoiding Verbosity In The Presentation Layer

August 29th, 2008

Most languages and technologies used in web applications come with their own unique naming conventions - which is unfortunate, but necessary, because diversity is important. Languages like JavaScript and PHP use camelCase, CSS uses-hyphenated-delimiters, and ASP.NET / Java / and the like adhere to the conventions used in their respective libraries and frameworks. Managing the different naming conventions in a web application can be difficult, but with discipline, embracing each language's conventions can provide some great benefits.

A common mistake I've made in the past, was trying to make all languages adhere to a single convention. As a budding PHP / ASP developer I took the-single-convention-for-all-languages approach. In retrospect, I used this approach because I didn't completely understand the language I was using, and in order to compensate for this lack of knowledge, I'd try to meld the languages into the mental model I understood best. This was a mistake.

Today, I find that working with the conventions of the language facilitates re-use (experts in the language understand what I'm doing), promotes portability (modules can be used across projects regardless of server-side technologies), encourages global collaboration (open source modules and plug-ins can be easily consumed and contributed to), and helps to a nurture a more maintainable application (developers from other language domains can easily maintain the application with a relatively small learning curve). Like a carpenter working with fine material, I embrace working with the grain of each language. It's also fair to mention that breaking free from the monocultured (one-size-fits-all) approach to naming conventions provides a broader perspective, and also makes your development skills more universal - it might even open the door to different development domains in the future.

Then there's the discussion on name length, verbosity, and using meaningful names. Steve McConnell suggests that the optimum name size for a variable or function is between 8 and 20 characters (Chapter 11, Code Complete), but with tools like ReSharper (for renaming / refactoring etc...) I find myself using names well over 30 characters. So names like GetApproveeTotalFromNamedBasket are a common occurrence in my code. However, like most things, verbosity does need balance (everything in moderation right?). In the business layer, descriptive names are a godsend - they jog my memory as I rediscover what the module I wrote last month was supposed to do. But... in the presentation layer languages (like JavaScript, CSS,  ASP.NET, or XHTML) you may want to reconsider using long descriptive names. Since verbose, long running descriptive names in the presentation layer are passed over the network and can degrade performance. Often times these verbose names are combined together - throw in ASP.NET name mangeling, start hooking in verbose CSS definitions, and then start inserting JavaScript events. All this compounds quickly and result in large page payloads filled with elements like the following:

<div id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent
 _PanelForTheBestReviews"
<a onclick="LinkButtonClick_ThankYouForTakingTheTimeToReadThis();" 
 id="ctl00_ContentPlaceHolderForAllTheBestImprotantContent_
 RepeaterForAllMyFavoriteBookReiews_ctl00_
 LinkButtonMarkReviewAsFavorite"
 class="LinkFormatingCssClass SelectedLinkFormatingCssClass" 
 href="javascript:__doPostBack( 
 ctl00$ContentPlaceHolderForAllTheBestImprotantContent$ 
 RepeaterForAllMyFavoriteBookReiews$ctl00$LinkButtonMarkReviewAsFavorite'
 ,'')">Mark As Favorite </a> 

Note: That mess of code above would fire a JavaScript event then an ASP.NET event. It's the result of placing an ASP.NET LinkButton, inside a Repeater, inside a Panel, inside a Masterpage, and adding a JavaScript event along with some CSS. We can see that using long names in the presentation layers results in a mess of text. It's also fair to mention that the ASP.NET MVC Framework lets developers write cleaner presentation code.
Sure, everyone cites premature optimization as the root of all evil, and we do live in a world of gzip file compression and JavaScript minifiers. But... keeping names short in CSS, ASP.NET, and XHTML isn't hard as long as you're mindful of the final goal. Smaller names in the presentation layer will reduce the amount of data transferred over the network which increase the performance of the application.

Joseph Smarr of Plaxo.com once said:

Web applications are only slow if you let them get slow - Douglas Crockford, Alex Russell and Joseph Smarr: On the Past, Present and Future of JavaScript [30:00]

My preference (project requirements warranting) is to keep things short and concise in the presentation languages while using longer descriptive names outside the presentation languages. What's your preference?

Free: Win a Copy of: JavaScript: The Good Parts by Douglas Crockford

July 29th, 2008

JavaScript: The Good Parts by Douglas Crockford is an excellent book. At 140+ pages this book is approachable and easy to read. The writing style is terse and clear, and it's crammed with good advice.

I thoroughly enjoyed this book and would like to give a copy away. You can read my review here.

Contest Rules:

  • Comment on this post.
  • Leave a valid email in the email comment field.
  • The winner will be chosen at random and notified through email on Oct 1st.
  • I pay for shipping.

Good Luck!

This contest has commenced, and the winner is Luke Maciak!

Author: Adam Kahtava Categories: Book, Contest, JavaScript Tags:

Book Reviewed: JavaScript: The Good Parts by Douglas Crockford

June 7th, 2008

Weighing in at 140+ pages of content, JavaScript: The Good Parts [Douglas Crockford] cuts through the obscurities, pleasantries, and filler found in most technical books. Instead, this book dives straight into the heart of the JavaScript language. It presents the clearest comprehensive explanation of what makes JavaScript a great programming language that I've encountered to date. It nails the important concepts, like JavaScript's: object oriented nature, its classless (pseudoclassical) nature, and functional nature. While covering the fundamentals like JavaScript's: functions, lexical scoping, lambdas, prototypal inheritance, and functional inheritance.

This book's size makes it approachable for all audiences, its style is terse and concise. This book has the potential to do for JavaScript, what Richie's inspirational classic the C Programming Language did for the C language.

JavaScript is the programming language of the web (AJAX), and this book will guide you through the good parts of this often misunderstood language - while this book is an excellent reference, it is not intended to replace JavaScript: The Definitive Guide, you'll do best to have both these books on hand.

If you enjoyed (or are considering) this book then you may want to learn more of what Douglas Crockford has to say, check out his great JavaScript video series on the YUI Theater.

I highly recommend this book. View my review on Amazon.