Announcing AJAX Libraries API: Speed up your Ajax apps with Google’s infrastructure

Category: Ajax, JavaScript, Library, Google

I just got to announce the Google AJAX Libraries API which exists to make Ajax applications that use popular frameworks such as Prototype, Script.aculo.us, jQuery, Dojo, and MooTools faster and easier for developers.

Whenever I wrote an application that uses one of these frameworks, I would picture a user accessing my application, having 33 copies of prototype.js, and yet downloading yet another one from my site. It would make me squirm. What a waste!

At the same time, I was reading research from Steve Souders and others in the performance space that showed just how badly we are doing at providing these libraries. As developers we should setup the caching correctly so we only send that file down when absolutely necessary. We should also gzip the files to browsers that accept them. Oh, and we should probably use a minified version to get that little bit more out of the system. We should also follow the practice of versioning the files nicely. Instead, we find a lot of jquery.js files with no version, that often have little tweaks added to the end of the fils, and caching is not setup well at all so the file keeps getting sent down for no reason.

When I joined Google I realised that we could help out here. What if we hosted these files? Everyone would see some instant benefits:

• Caching can be done correctly, and once, by us... and developers have to do nothing
• Gzip works
• We can serve minified versions
• The files are hosted by Google which has a distributed CDN at various points around the world, so the files are "close" to the user
• The servers are fast
• By using the same URLs, if a critical mass of applications use the Google infrastructure, when someone comes to your application the file may already be loaded!
• A subtle performance (and security) issue revolves around the headers that you send up and down. Since you are using a special domain (NOTE: not google.com!), no cookies or other verbose headers will be sent up, saving precious bytes.

This is why we have released the AJAX Libraries API. We sat down with a few of the popular open source frameworks and they were all excited about the idea, so we got to work with them, and now you have access to their great work from our servers.

Details of what we are launching

You can access the libraries in two ways, and either way we take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc.

The first way to access the scripts is simply be using a standard <script src=".."> tag that points to the correct place.

For example, to load Prototype version 1.6.0.2 you would place the following in your HTML:

PLAIN TEXT

HTML:

1.  
2. <script src="http://ajax.googleapis.com/ajax/libs/prototype/1.6.0.2/prototype.js"></script>
3.  

The second way to access the scripts is via the Google AJAX API Loader's google.load() method.

Here is an example using that technique to load and use jQuery for a simple search mashup:

PLAIN TEXT

HTML:

1.  
2. <script src="http://www.google.com/jsapi"></script>
3. <script>
4.   // Load jQuery
5.   google.load("jquery", "1");
6.  
7.   // on page load complete, fire off a jQuery json-p query
8.   // against Google web search
9.   google.setOnLoadCallback(function() {
10.     $.getJSON("http://ajax.googleapis.com/ajax/services/search/web?q=google&;v=1.0&;callback=?",
11.  
12.       // on search completion, process the results
13.       function (data) {
14.         if (data.responseDate.results &&
15.             data.responseDate.results.length>0) {
16.           renderResults(data.responseDate.results);
17.         }
18.       });
19.     });
20. </script>
21.  

You will notice that the version used was just "1". This is a smart versioning feature that allows your application to specify a desired version with as much precision as it needs. By dropping version fields, you end up wild carding a field. For instance, consider a set of versions: 1.9.1, 1.8.4, 1.8.2.

Specifying a version of "1.8.2" will select the obvious version. This is because a fully specified version was used. Specifying a version of "1.8" would select version 1.8.4 since this is the highest versioned release in the 1.8 branch. For much the same reason, a request for "1" will end up loading version 1.9.1.

Note, these versioning semantics work the same way when using google.load and when using direct script urls.

By default, the JavaScript that gets sent back by the loader will be minified, if there is a version supported. Thus, for the example above we would return the minified version of jQuery. If you specifically want the raw JavaScript itself, you can add the "uncompressed" parameter like so:

PLAIN TEXT

JAVASCRIPT:

1.  
2. google.load("jquery", "1.2", {uncompressed:true});
3.  

Today we are starting with the current versions of the library, but moving forward we will be archiving all versions from now onwards so you can be sure they are available.

For a full listing of the currently supported libraries, see the documentation.

Here I am, talking about what we are doing in two short slides:

The Future

This is just the beginning. We obviously want to add more libraries as you find them useful. Also, if you squint a little you can see how this can extend even further.

If we see good usage, we can work with browser vendors to automatically ship these libraries. Then, if they see the URLs that we use, they could auto load the libraries, even special JIT'd ones, from their local system. Thus, no network hit at all! Also, the browser could have the IP addresses for this service available, so they don't have the hit of a DNS lookup. Longer lived special browser caches for JavaScript libraries could also use these URLs.

The bottom line, and what I am really excited about, is what this could all mean for Web developers if this happens. We could be removed of the constant burden of having to re-download our standard libraries all the time. What other platform makes you do this?! Imagine if you had to download the JRE everytime you ran a Java app! If we can remove this burden, we can spend more time flushing out functionality that we need, and less time worrying about the actual download bits. I am all for lean, but there is more to life.

Acknowledgements

I want to acknowledge the other work that has been done here. Some libraries such as jQuery and Dean Edwards Base were already kind of doing this by hot linking to their Google Code project hosting repository. We thought this was great, but we wanted to make it more official, and open it up to libraries that don't use our project hosting facilities.

Also, AOL does a great job of hosting Dojo already. We recommend using them for your Dojo needs, but are proud to also offer the library. Choice is good. Finally, Yahoo! placed the YUI files on their own CDN for all to use.

Blogged with the Flock Browser

Enable code coloring in Dreamweaver for Drupal by adding file extensions recognized by Dreamweaver

Introduction

This TechNote applies to the following related symptoms in Adobe Dreamweaver:

• When opening a file, you see this error message: "Can't find a valid editor for this file extension."
• The color-coding in Code view isn't matching the color-coding for the file type you want.
• The server-model functionality isn't available for your file type.
• You cannot open a page in Design view. It only opens in Code view.
• When you go to File > Save, or File > Open, you don't see the file type you want.

Dreamweaver ships with the ability to edit and display many different file types. This TechNote focuses on customizing Dreamweaver to recognize new file types by editing the Extensions.txt and MMDocumentTypes.xml files, and setting the Open In Code View settings to see the new file types in Design view.

• The Extensions.txt file
  The Extensions.txt file is a text file listing all file types recognized by Dreamweaver. This file can be edited in any external text editor like Notepad or Text Editor to add to the list of recognized file types. Do not modify the Dreamweaver configuration files in Dreamweaver itself.
   
• The MMDocumentTypes.xml file
  The MMDocumentTypes.xml file contains definitions of document types as well as a list of file extensions associated with each recognized document type. Adding file extensions to the Extensions.txt file allows Dreamweaver merely to recognize a file extension and allow files of this type to be opened in Dreamweaver. Adding file extensions to the MMDocumentTypes.xml file tells Dreamweaver how to treat this new file extension and to which document type this file extension belongs.

  Note: For the purpose of this TechNote, only basic aspects of editing the MMDocumentTypes.xml file will be discussed. For a detailed overview of editing this file, see Extending Dreamweaver (from within Dreamweaver, choose Help > Extending Dreamweaver, and search on MMDocumentTypes.xml).

• Open in Code View
  The Open in Code View preference identifies file extensions that do not allow Design view. After following the instructions in this TechNote, be sure to remove the file extension (if it is listed) from the Open In Code View preference to allow file editing in Design view. To set this preference, choose Edit > Preferences (Windows) or Dreamweaver > Preferences (Mac OS), and locate the File Types / Editors category.

Editing the Extensions.txt file

When opening a file that Dreamweaver doesn't recognize, you see this error message: "Can't find a valid editor for this file extension." New extensions can be added to the list of extensions that Dreamweaver recognizes. To add new extensions, edit the Extensions.txt file. Entries in the Extensions.txt file also control the order in which files are listed in the File > Open and File > Save dialog boxes. For the purpose of demonstration, we will add the .inc file type to Dreamweaver.

Note: This procedure requires you to locate hidden files, hidden folders and extensions for known file types. By default, Windows Explorer doesn't show hidden files, hidden folders, and file name extensions that it recognizes.

To show hidden files, hidden folders, and extensions for known file types:

1. In Windows Explorer, do one of the following:
   • In Windows XP, choose Tools > Folder Options.
   • In Windows Vista, choose Organize > Folder and Search Options.
2. Click the View tab in the Folder Options dialog box.
3. In Advanced Settings, select Show Hidden Files And Folders.
4. Deselect Hide Extensions For Known File Types.
5. Click OK.

To add file types to the Extensions.txt file:

1. Locate the Extensions.txt file within the Dreamweaver user configuration folder. The location of this folder depends on the operating system and the version of Dreamweaver:
   • Dreamweaver CS3 on Windows Vista:
     C:\Users\[username]\AppData\Roaming\Adobe\Dreamweaver 9\Configuration
   • Dreamweaver 8 on Windows Vista:
     C:\Users\[username]\AppData\Roaming\Macromedia\Dreamweaver 8\Configuration
   • Dreamweaver CS3 on Windows XP:
     C:\Documents and Settings\[username]\Application Data\Adobe\Dreamweaver 9\Configuration
   • Dreamweaver 8 on Windows XP & 2000:
     C:\Documents and Settings\[username]\Application Data\Macromedia\Dreamweaver 8\Configuration
   • Dreamweaver CS3 on Mac OS X:
     Mac HD:Users:[username]:Library:Application Support:Adobe:Dreamweaver 9:Configuration
   • Dreamweaver 8 on Mac OS X:
     Mac HD:Users:[username]:Library:Application Support:Macromedia:Dreamweaver 8:Configuration
   Note: Edits to this file will only be available to the current user. Changes made to files within the user profile will not be available to other users. For more information about manually editing Dreamweaver configuration files in a multi-user environment, please see Customizing Dreamweaver.
   
2. Open Extensions.txt in any external text editor like Notepad or Text Editor. Do not modify the Dreamweaver configuration files in Dreamweaver itself.
   
3. Add the extension to the All Documents line. Extensions must be in uppercase letters and separated by commas. (INC should already be listed by default. If not, add it.)

   Example:  HTML,HTM,SHTM,SHTML,INC

4. To add extensions to an existing document group, add the extension to the extension list for the desired group. To add a new document group, add a new line that contains the new document type as well as a listing of associated extensions.

   Example:  INC:Include Files

   (This can also be added to the Server Side Include list already within the file.)

5. Save the file and restart Dreamweaver.
6. To see the changes, open Dreamweaver and open a file with the newly added file extension. It should now open in Code view only in Dreamweaver. Select File > Save As, and click the Save As Type pop-up menu. You should now see an option for Include Files with *.inc as the recognized file extension. It's the same for the Files Of Type pop-up menu in File > Open.

Note:  The order in which extensions are listed is the order in which they will appear in the File > Open and File > Save dialog boxes.

To get Design view, color coding, and server behavior functionality (if applicable) working, you need to edit the MMDocumentTypes.xml file, as described below.

The MMDocumentTypes.xml file

Where the Extensions.txt file contains the list of extensions recognized by Dreamweaver, the MMDocumentTypes.xml file contains information about the server model, color coding style, descriptions, and so forth for each known document type.

In addition to adding extensions to the Extension.txt file, new extensions must also be added to the file extension lists for the associated document type. If not, Dreamweaver will not know how to display this file type and will open it in Code view by default. If this extension is not associated with any defined document type, a new document type should be created. To create a new document type, see Extending Dreamweaver (from within Dreamweaver, choose Help > Extending Dreamweaver, and search on MMDocumentTypes.xml).

Note:  For the purpose of this TechNote, 'document type definition' refers to files that contain information about documents recognized by Dreamweaver and are not to be confused by 'DTDs' mentioned in XML documentation.

Steps to add extensions to a document type definition in the MMDocumentTypes.xml file:

1. Locate the MMDocumentTypes.xml file in the main Dreamweaver configuration folder (not the Dreamweaver user configuration folder). The location of this folder depends on the operating system and the version of Dreamweaver:
   • Dreamweaver CS3 on Windows Vista & XP:
     C:\Program Files\Adobe\Adobe Dreamweaver CS3\Configuration\DocumentTypes
   • Dreamweaver 8 on Windows Vista, XP & 2000:
     C:\Program Files\Macromedia\Dreamweaver 8\Configuration\DocumentTypes
   • Dreamweaver CS3 on Mac OS X:
     Mac HD:Applications:Adobe Dreamweaver CS3:Configuration:Document Types
   • Dreamweaver 8 on Mac OS X:
     Mac HD:Applications:Macromedia Dreamweaver 8:Configuration:Document Types
2. Open MMDocumentTypes.xml in any external text editor like Notepad or Text Editor. Do not modify the Dreamweaver configuration files in Dreamweaver itself.
3. Find the tag set for the desired document type. Below is the default document type definition for HTML documents from the MMDocumentTypes.xml file:
   
   <documenttype id="HTML" internaltype="HTML" winfileextension="html,htm,shtml,shtm,stm,tpl,lasso,xhtml" macfileextension="html,htm,shtml,shtm,tpl,lasso,xhtml,ssi" file="Default.html" writebyteordermark="false">
4. Add the desired extension to the  winfileextension  and  macfileextension  attributes of the  documenttype  tag. For example:
   winfileextension="html,htm,shtml,shtm,stm,tpl,lasso,xhtml,inc"
   

   The code above adds the INC file extension to the list of files that Dreamweaver treats as HTML files. Adding extensions to the Mac OS and Windows lists for this file types allows Dreamweaver to open this file type in Design view as other files with defined HTML file extensions.

5. Save MMDocumentTypes.xml and restart Dreamweaver.
6. To see the changes, open Dreamweaver and open a file that has the newly added file extension. You should see that Design view, code coloring and server behavior functionality (if applicable) are working now.

Note:  The order in which extensions are listed is important. The first extension in the extensions lists will be the default extension used for this file type.

Note:  If you made a backup of the MMDocumentTypes.xml and left it in the Configuration/DocumentTypes folder, you will see multiple warning messages pop up when you launch Dreamweaver that look like this:

'The Document Type "HTML" will not be added because it uses a file extension that is already associated with a prior Document Type.'

To stop these warning messages, move your backup copy of the MMDocumentTypes.xml file outside the Configuration/DocumentTypes folder. For example, move it to the desktop. You will also get this error message if you have the same file type listed more than once in the MMDocumentTypes.xml.

Edit in Code View preference

The final step is to check the File Types / Editors preference settings (Edit > Preferences) and make sure that this file extension is not listed in the Open In Code View field. By default, the INC file extension appears on this list. Remove ".inc" from the Open in Code View list and files with this extension should now be viewable in Design view.

Blogged with the Flock Browser

Fighting the Android: Nokia buys and open sources Symbian

Nokia announced plans today to transform the Symbian mobile phone operating system into an open source platform. Nokia, which already owns roughly half of all shares of Symbian, is in the process of obtaining the other half from various holders for €264 million. The company has partnered with several other major handset makers to launch the new nonprofit Symbian Foundation, which will facilitate the liberation of the platform.

Several core Symbian Foundation members are contributing their own Symbian-based technologies so that the best third-party enhancements can be converged into a single unified stack. This will include Nokia's own S60 platform, the UIQ graphical user interface layer which is jointly owned by Sony Ericsson and Motorola, and NTT DoCoMo's MOAP. These components will be available soon under a royalty-free license to all members of the foundation. Within two years, the platform will be completely open source and will be distributed under the Eclipse Public License (EPL), a moderately permissive license that requires downstream patent grants.

"Establishing the Foundation is one of the biggest contributions to an open community ever made," said Nokia CEO Olli-Pekka Kallasvuo in a statement. "Nokia is a strong supporter of open platforms and technologies as they give the freedom to build, maintain and evolve applications and services across device segments and offer by far the largest ecosystem, enabling rapid innovation. Today's announcement is a major milestone in our devices software strategy."

Symbian is currently the most widely-used smartphone platform, but its popularity and relevance have been declining as handset makers moved towards other platforms, including Windows Mobile and Apple's iPhone, as well as Linux and other open source alternatives that reduce licensing costs and offer more flexibility. The Symbian's business model and development strategy were far out of step with the direction in which the industry was collectively moving. Nokia's efforts to completely open the platform will change that and make Symbian a much stronger contender in the next-generation mobile space.

This could give Symbian a competitive boost against other open phone operating systems such as the one created by the LiMo Foundation and Google's Android platform which has reportedly run into a few snags with major carriers.
Fighting the Android: Nokia buys and open sources Symbian

Don’t forget to be part of Firefox’s Download Day!

Mark your calendar, wrap a ribbon around your finger or write a little sticky yellow note. Download Day will start on June 17, 2008.

Blogged with the Flock Browser

The Internet Star

Blogged with the Flock Browser

Design Stencils - Yahoo! Design Pattern Library

Download a Stencil KitYahoo! Design Stencil Kit version 1.0 is available for OmniGraffle, Visio (XML), Adobe Illustrator (PDF and SVG), and Adobe Photoshop (PNG), and covers the following topics: * Ad Units * Calendars * Carousels * Charts and Tables * UI Controls * Form Elements * Grids * Menus and Buttons * Mobile - General * Mobile - iPhone * Navigation and Pagination * OS Elements * Placeholder Text * Screen Resolutions * Tabs * Windows and ContainersDOWNLOADOmniGraffleVisio (XML)PDFPNGSVGCreative Commons LicenseThis work is licensed under a Creative Commons Attribution 2.5

Design Stencils - Yahoo! Design Pattern Library

Blogged with the Flock Browser