In the “Dependencies” section of the article, Stefanov describes using the onLoad or onReadyStateChange events of the dynamically generated script tag to receive notification when that script has been loaded by the browser.  Once you know it’s loaded, then you know it’s safe to begin using the code it contains.

This works great for Firefox and IE, but fails completely in the Safari browser.  Safari doesn’t implement onLoad notifications for script tags.  This forces you to abandon the onLoad technique and instead use the technique of embedding something at the end of each script file to signal when the file has been loaded. 

The script libraries for the Windows Live sites use this technique – every source file contains a function call at the bottom that tells a central notifier that it has been loaded.  Other code can ask the notifier to signal them when a file or set of files have been loaded.  This works in all browsers without relying on diverging browser idiosyncracies. 

Unfortunately, this also requires that all the JavaScript you want to load dynamically (using this technique) knows about your particular load notification pattern.  If you want to dynamically load JavaScript from multiple libraries or authors, you will either end up with multiple notification systems (which should coexist peacefully) or you’ll have to modify those files to use your load notifier.  This is bad from a design standpoint because it requires that all your code modules have carnal knowledge of your application - erodes the modularity of the source files – or require that all your code modules follow the design patterns of a particular JavaScript toolkit, like DoJo or Prototype or YUI.  The latter isn’t a terrible tradeoff except that it limits your options.

 Discovered via a note by Steve Trefethen on FriendFeed.

Share/Bookmark

While zooming around in images on the 3D wall, hit Tab to select the Search box in the top right corner of the screen (or mouse click on it).  You’ll see the traditional vertical bar edit insertion caret / cursor ready for input as well as half a dozen search engines listed below the search box: Google Image Search, Yahoo Image Search, Flickr, DeviantArt, PhotoBucket, and SmugMug. 

Type your search term, say “Giant Squid”, and press Enter to activate that search on the currently selected search engine.  The Wall will begin populating with image results immediately.  Click on another search engine and PicLens will issue your search query to that engine immediately. 

This makes it pretty darn easy to flip between search engines to see how the same terms can return vastly different image results.  Google image search will give you very literal results – generally photos of large squids laid out on the pier or parking lot.  DeviantArt or Flickr, on the other hand, are much more likely to return more artistic images, paintings, or face shots of a guy named “Squid”.  Let us know if this sort of search domain-hopping is useful to you.

In addition to text editing, this week’s PicLens release has several new features: 

• Text display
• Text editing (for Search)
• Search
• Improved image quality in Flickr thumbnails on the Wall
• Improved integration between PicLens Lite and PicLens
• Multi-page RSS support
• View in PicLens photo galleries on your local hard disk generated by PicLens Publisher 
• Did I mention text?

Sharper Flickr Thumbnails 

We’ve stepped up the size of thumbnail images we ask for from Flickr.  This results in much sharper images in the wall, but the cost is it takes longer to downoad them.  Let us know what you think of this (in comments on this blog or in email to feedback (at) piclens.com) - is it too slow for you, or is it the right thing to do for best picture quality?  It definitely looks great.

Multipage RSS

One of the drawbacks to the early uses of RSS was that RSS was never intended to be a permenant record or to contain endless amounts of data.  It’s a simple file format.  If you put a lot of data into an RSS feed, everybody has to download the entire RSS feed to see any of it.  Blogs deal with this by “aging” the items in the RSS feed – old items are removed from the end when new items are pushed onto the front.  Archives are broken down by month, so that each archive RSS feed doesn’t get too big to handle.

This doesn’t work so well for huge image databases like Flickr or DeviantArt.  Flickr actually does provide an RSS feed of a user’s photo stream, but it is restricted to the 20 most recent items.  20 is a lot for a web page, but it’s a drop in the ocean for PicLens.

Austin was poking around in RSS for some other PicLens work when he stumbled upon a bit of esoterica that got him really excited.  Not the photos returned by a particularly curvy search query (though those do excite him as well), but a technique to encode a reference to previous and next pages of an RSS feed in the RSS feed.  Essentially, you can make a really big RSS feed out of a linked list of smaller, more manageable RSS feed chunks.  This is a great solution to the problem of managing large amounts of data in bite sized chunks that can be loaded only when needed.

PicLens Publisher would be a natural to emit multipage RSS.  We will certainly bring up multipage RSS as a site suggestion when chatting with big sites like Yahoo, Flickr, DeviantArt and others.

View Local PicLens Publisher Galleries

An eleventh hour addition to this PicLens 1.6.1 release is the ability to view galleries generated by PicLens Publisher on your local hard disk.  In Firefox, just do File: Open File and select the gallery.html file from the directory created by PicLens Publisher.  Viola! You can preview how your gallery will look in PicLens before uploading the files to your web server.

There are some additional angles on this feature but we’re still fine tuning it so I’ll save that for another day.  Besides, if I spill all the beans at once, where’s the air of mystery and adventure in that?  ;>

Share/Bookmark