Blogs

Book: The Art & Science of JavaScript

Tagged:  

If you haven't heard, a new JavaScript book is out on the market. The text is published by Sitepoint and is coauthored by James Edwards, Michael Mahemoff, Ara Pehlivanian, Cameron Adams, Dan Webb, Christian Heilmann and Simon Willison.

Who the publisher says the book is for:

This book is targeted at intermediate JavaScript developers who want to take their JavaScript skills to the next level without sacrificing web accessibility or best practice. If you’ve never written a line of JavaScript before, this probably isn’t the right book for you—some of the logic in the later chapters can get a little hairy.

If you have only a small amount of experience with JavaScript, but are comfortable enough programming in another language such as PHP or Java, you’ll be just fine—we’ll hold your hand along the way, and all of the code is available for you to download and experiment with on your own.

And if you’re an experienced JavaScript developer, we would be very, very surprised if you didn’t learn a thing or two. In fact, if you only learn a thing or two, you should contact us here at SitePoint—we may have a book project for you to tackle!

What they say you'll learn:

* Create a slick Google Maps and Flickr mashup.
* Build your own fully accessible 3D maze.
* Have some fun with draggable and sortable table columns.
* Give your site some extra personality with client-side badges.
* Write better code faster using metaprogramming techniques.
* Create stunning vector graphics using the canvas element.
* Become a debugging expert using pro-level Firebug tricks.

What's in the TOC:

Chapter 1: Fun with Tables
Chapter 2: Creating Client-side Badges
Chapter 3: Creating Vector Graphics with canvas
Chapter 4: Debugging and Profiling with Firebug
Chapter 5: Metaprogramming with JavaScript
Chapter 6: Building a 3D Maze with CSS and JavaScript
Chapter 7: Flickr and Google Maps Mashups

Visit the book's homepage at Sitepoint

If you've had a chance to start reading this book, please post your review in the comments.

Will Internet Explorer 8 Pass the Acid2 and Acid3 Tests?

Tagged:  

Over at CNET's News.com they have posted an interesting story about if Internet Explorer 8 will pass the Acid2 and Acid3 test. The Acid tests are design to make it possible for web developers to create web sites that comply to standards so that they know that the design will be cross browser compliant.

Below is an excerpt from the post.

What will happen when you type http://webstandards.org/acid2 in your freshly installed IE 8? Will Acid2 be displayed correctly when you hit the test button?

Microsoft has been asked that question, but it has not given an answer. I think that the company is considering three possible scenarios.

One scenario could be that IE 8 will require users or authors to "opt in" to support standards. For example, in order to render Acid2 correctly, users could be required to modify IE 8's default settings. This breaks with the guidelines of the test, and IE 8 will therefore not pass in this scenario.

A second scenario could be that Microsoft requires Web pages to change the default settings by flagging that they really, really want to be rendered correctly. Web pages already have a way to say this (called "doctype switching," which is supported by all browsers), but Microsoft has all but announced that IE 8 will support yet another scheme.

If it decides to implement the new scheme, the Acid2 test--and all the other pages that use doctype switching--will not be rendered correctly.

A third scenario could be to hard-code the Web address of Acid2 into IE 8. This way, the page is given special treatment to make it look like the browser is passing the test. It should be obvious that this breaks the spirit of the test and doesn't warrant a passing grade.

I predict that Microsoft will implement at least one of these scenarios to limit the impact of standards. This would be damaging for the Web, and I therefore hope that my prediction is completely and absolutely wrong. The IE 8 team has shown that it can render Acid2 correctly. Now it's time for Microsoft to put its code to good use.

Read the full post here.

Hopefully Microsoft will get IE 8 to render Acid2 and Acid3 correctly for the good of the web (although, it won't make me change from Firefox).

As always we would love to hear your thoughts on this or any web related technologies. If you have something to say you can blog about it on this blog once you create a free account (once logged in just click on "Create content" => "Blog entry" and then blog).

Building User Interfaces Using Google Web Toolkit (GWT) : Video

Tagged:  

Today I found an interesting video about building user interfaces using the Google Web Toolkit (GWT). This was taken from a presentation at the IndicThreads.com Conference on Java Technology held in Pune, India (I found the video over at IndicThreads.com).

Below is an excerpt from the post:

Chris Schalk's session on 'Building User interfaces using GWT' presented at the IndicThreads.com Conference On Java Technology 2007 held in Oct 2007 in Pune, India.

This session serves as an up to date review of the latest technologies and methodologies for "Building User interfaces using GWT". Specifically covered is - What is Google Web Toolkit (GWT), the potential of Ajax, what GWT brings to Ajax, what GWT focuses on, the Ajax Architectural Shift, building Ajax apps with Java(TM) technology and important GWT applets.

The GWT Mission is to radically improve the web experience for users. This is achieved by allowing developers to use existing Java tools to build no-compromise Ajax for modern browser users.

Speaker- Chris Schalk is a Developer Advocate for Google and helps promote Google Ajax technologies around the world. He is also one of the original members of the OpenAjax Alliance. Prior to Google, Schalk was a Principal Product Manager and Java Evangelist for Oracle's application server and development tools division. While at Oracle, he worked to define the overall Web development experience for Oracle JDeveloper and ADF Faces (Trinidad). He is also the co-author of JavaServer Faces: The Complete Reference published through McGraw-Hill Osborne

To read the full post click here and you can watch the video below.


It is always nice to see more information on the GWT as it is a great tool for Java developers that would like to make Ajax applications.

Build a customizable RSS feed aggregator in PHP

Tagged:  

Over at IBM's developerWorks they have a good post on creating a RSS feed aggregator in PHP. As RSS has become a standard form of syndication for much of the webs content (especially in web 2.0 sites) the ability to aggregate feeds can be a good recourse.

Below is an excerpt from the post:

Functional components

The RSS function described in this article is made up of the following components, explained in the following order:

* Feed reader
* Feed sources input
* Feed aggregator
* Feed results output

These simple components combine to provide a powerful RSS feed aggregator function that can be integrated with other applications in a variety of ways. In the following sections, we will look inside the PHP code snippets that make up each of these components. Figure 2 depicts an overview of these functional components:

Figure 2. Overview of RSS functional components

Observe the following in Figure 2:

* The feed reader component does the bulk of the job and focuses on obtaining feeds provided by a given feed source. A feed source is nothing but a URL at which a particular content provider periodically syndicates the content for a given information category. For instance, a feed source might point to a URL at which the New York Times publishes all its latest news blurbs about the business category/channel using the XML-based RSS format.
* The feed aggregator component takes several user-specified feed sources as input and then it invokes the feed reader component to get all feed items from each customized feed source.
* The feed sources input component defines and reads the details about the user-specified feed sources. The feed source details can be provided in the form of a string stored in system memory, via an input file, or as records in a database.
* The feed results output component stores the aggregated RSS feed item results received from a particular feed source. It can store the results as a string in system memory, into a file, or into database tables.

To simplify our work, we will be combining the feed sources input and the feed results output components to be part of the feed aggregator component. (You can download a fully documented set of PHP source files for these components from the Download section.) You can extract these files to your machine and run them with your own customized set of RSS feed sources. As explained in a previous section, a PHP environment with XML and cURL library support is a prerequisite for doing this. (Refer to the Conclusion section to understand the many ways in which you can use the code for the RSS feed aggregator.)

You can read the full post here

You can download the code here.

As always we would love to hear about any interesting uses of RSS that you may have. You can write about them in this blog by signing up for a free account (once you login click on Create content => Blog Entry).

Alternate Ajax Techniques

Tagged:  

Today I found an interesting post on alternative Ajax techniques (meaning techniques that do not use the XMLHttpRequest object). It is interesting to look at other techniques to load content without a page refresh (although I know that some would say that if you don't use the XMLHttpRequest object that it isn't really Ajax at all).

Below is an excerpt from the post:

Dynamic Script Loading

The first alternate Ajax technique is dynamic script loading. The concept is simple: create a new <script/> element and assign a JavaScript file to its src attribute to load JavaScript that isn't initially written into the page. The beginnings of this technique could be seen way back when Internet Explorer 4.0 and Netscape Navigator 4.0 ruled the web browser market. At that time, developers learned that they could use the document.write() method to write out a <script/> tag. The caveat was that this had to be done before the page was completely loaded. With the advent of the DOM, the concept could be taken to a completely new level.

The Technique

The basic technique behind dynamic script loading is easy, all you need to do is create a <script/> element using the DOM createElement() method and add it to the page:

var oScript = document.createElement("script");

oScript.src = "/path/to/my.js";

document.body.appendChild(oScript);

Downloading doesn't begin until the new <script/> element is actually added to the page, so it's important not to forget this step. (This is the opposite of dynamically creating an <img/> element, which automatically begins downloading once the src attribute is assigned.)

Once the download is complete, the browser interprets the JavaScript code contained within. Now the problem becomes a timing issue: how do you know when the code has finished being loaded and interpreted? Unlike the <img/> element, the <script/> element doesn't have an onload event handler, so you can't rely on the browser to tell you when the script is complete. Instead, you'll need to have a callback function that is the executed at the very end of the source file.

Example 1

Here's a simple example to illustrate dynamic script loading. The page in this example contains a single button which, when clicked, loads a string ("Hello world!") from an external JavaScript file. This string is passed to a callback function (named callback()), which displays it in an alert. The HTML for this page is as follows:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

  <head>

    <title>Example 1</title>

    <script type="text/javascript">//<![CDATA[

        function makeRequest() {

          var oScript = document.createElement("script");

          oScript.src = "example1.js";

          document.body.appendChild(oScript);

        }



        function callback(sText) {

          alert("Loaded from file: " + sText);

        }

    //]]>

    </script>

  </head>

  <body>

    <input type="button" value="Click Me" onclick="makeRequest()" />

  </body>

</html>

The JavaScript file example1.js contains a single line:

callback("Hello world!");

When the button is clicked, the makeRequest() function is called, initiating the dynamic script loading. Since the newly loaded script is in context of the page, it can access and call the callback() function, which can do use the returned value as it pleases. This example works in any DOM-compliant browsers (Internet Explorer 5.0+, Safari, Firefox, and Opera 7.0+), try it for yourself or download the examples.

More Complex Communication

Sometimes you'll want to load a static JavaScript file from the server, as in the previous example, but sometimes you'll want to return data based on some sort of information. This introduces a level of complexity to dynamic script loading beyond the previous example.

First, you need a way to pass data to the server. This can be accomplished by attaching query string arguments to the JavaScript file URL. Of course, JavaScript files can't access query string information about themselves, so you'll need to use some sort of server-side logic to handle the request and output the correct JavaScript. Here's a function to help with the process:

function makeRequest(sUrl, oParams) {

  for (sName in oParams) {

    if (sUrl.indexOf("?") > -1) {

      sUrl += "&";

    } else {

      sUrl += "?";

    }

    sUrl += encodeURIComponent(sName) + "=" + encodeURIComponent(oParams[sName]);

  }

  var oScript = document.createElement("script");

  oScript.src = sUrl;

  document.body.appendChild(oScript);

}

This function expects to be passed a URL for a JavaScript file and an object containing query string arguments. The query string is constructed inside of the function by iterating over the properties of this object. Then, the familiar dynamic script loading technique is used. This function can be called as follows:

var oParams = {

  "param1": "value1",

  "param2": "value2"

};

makeRequest("/path/to/myjs.php", oParams)

You can read the full post here.

It is always interesting to look at different ways to do things, while a different technique may not be useful in your application it is good to know that they exist for occasions when that become useful (for instance if you want to load data cross domain you can't use the XMLHttpRequest object).

JavaScript Cheat Sheet

Tagged:  

This one's an oldie, but a goodie. A few years ago the folks over at ilovejackdaniels.com put together a JavaScript Cheat Sheet that is designed to act as a reference sheet for JavaScript functions and methods.

The reference material covers:
* Functions & Methods
* Regular Expressions
* XMLHttpRequest
* JavaScript in HTML
* and last but not least, Event Handlers

Click to download:

Their other cheat sheets include:

If you'd like to get your hands on even more cheat sheets, check out this post on menekali.com that lists a ton of them.

*update*
If you're looking for some UNIX & Perl Cheat Sheets, check out Peteris Krumins blog. Thanks Peteris!

Tatami integrates the Google Web Toolkit and the DOJO framework

The Tatami project is an attempt to integrate the Google Web Toolkit (GWT) and the DOJO JavaScript framework. Tatami pulls in DOJO's rich widgets and utilities (like fisheye, slider, drag and drop functionality) and makes them accessible to the GWT as widgets and helpers. Tatami is compatible with the GWT 1.4 final version.

Check out the demo (may run slowly because files are being served from SVN)

Last month's release of Tatami-1.1 contained some new features, they are:

* DOJO 1.0 wrapped

* DropdownDatePicker and DropdownTimePicker with validation.

* Slider with labels an rule mark.

* The GFX package of DOJO wrapped. (Circle, Rectangle, Path, scaling...)

Visit the Tatami project homepage.

LiveValidation - JavaScript Form Validation

Tagged:  

Another useful validation script to take a look at, named LiveValidation, is a JavaScript Form Validation script that can easily add some slick UI enhancements to your existing forms. This definitely beats rolling your own form validation, especially if you tend to throw in some old school alerts like alert("Please enter your first name");

* Visit the LiveValidation Homepage

* View some Examples

* Download the Script

CSS Gradient Text Effect

Tagged:  

Over at Web Designer Wall they have posted a good tutorial on creating a gradient header using CSS. The technique is based on an empty span tag a PNG and the position:absolute CSS property (the technique is 100% CSS, no JavaScript or Flash). Compatible tested browsers include Firefox, Opera, Safari and Internet Explorer.

Below is an excerpt from the tutorial:

How does this work?

The trick is very simple. Basically we are just adding a 1px gradient PNG (with alpha transparency) over the text.

screenshot

The HTML markups

<h1><span></span>CSS Gradient Text</h1>

The CSS

The key point here is: h1 { position: relative } and h1 span { position: absolute }

h1 {
  font: bold 330%/100% "Lucida Grande";
  position: relative;
  color: #464646;
}
h1 span {
  background: url(gradient.png) repeat-x;
  position: absolute;
  display: block;
  width: 100%;
  height: 31px;
}

That’s it! You are done. Click here to view my demo page.

Make it work on IE6

Since IE6 doesn’t render PNG-24 properly, the following hack is required in order to display the transparent PNG (add anywhere in between the <head> tag):

<!--[if lt IE 7]>

<style>
h1 span {
  background: none;
  filter: progid:DXImageTransform.Microsoft.AlphaImageLoader(src='gradient.png', sizingMethod='scale');
}
</style>

<![endif]-->

This is why we hate IE 6!

jQuery prepend version (for semantic lovers)

If you don’t want to have the empty <span> tag in the heading, you can use Javascript to prepend the <span> tag. Here is a sample using jQuery prepend method:

<script type="text/javascript" src="jquery.js"></script>

<script type="text/javascript">
$(document).ready(function(){

  //prepend span tag to H1
  $("h1").prepend("<span></span>");

});
</script>

You can view the demo here or download it here. To read the full tutorial click here.

If you make any cool headers using this technique I would love to hear about them. You can either leave them in the comments or blog about them at this blog once you create a free account.

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.

Syndicate content