Monday, March 3rd, 2008
Recently a mutual friend of Jennifer 8 Lee’s put her in touch with me for help with a Google Maps utility for her new book’s blog. The book, called The Fortune Cookie Chronicles, comes out today, and she wanted help setting up a little map of her book appearances. The map is up now, and seems to be working well!
The code reads in an XML file of appearances, then uses the Google Maps API to put each point on the map. To save the trouble of having to type everything twice, we’re also using it to create the text list of appearances below. After a little thought and testing, I added the ability to group appearances by city, and have a link that opens up the map zoomed in on that location.
Once again, the Google Maps API has proved to be fun to work with. I love having open APIs for such cool services, and Google seems to add to the featureset frequently. The only real problem I had was that the geocoder service seemed to be slow and didn’t always return all of the requested coordinates. I might have just been doing my testing when the service was having problems, but I went ahead and added coordinates for all the locations to improve performance and reliability.
Some day if I have time, I’d love to clean up the javascript and make it more general. I think it might be interesting to make a WordPress plugin for mapping book signing appearances or other kinds of interesting geographical lists.
Posted in Javascript | No Comments »
Thursday, February 7th, 2008
While Dojo 1.0’s release improved the documentation available for the dojo toolkit, I still often find myself having to resort to reading the source code itself to get things working. In particular, dojo’s documentation for the programmatic use of some of its widgets and utilities seems to be lacking.
As part of the uPortal 3 theme update effort, I’ve been trying to get dojo 1.0.2’s drag and drop support working. We used a custom dojo-based drag and drop handler for moving portlets in uPortal 2.6, but I wanted to begin using the new, official drag and drop engine included in the dojo 1.0 distribution. Unfortunately, the documentation is mostly geared towards using dojo with parseOnLoad enabled.
Through some trial and error and source code reading, I discovered that the following steps are generally necessary to enable dojo’s drag and drop programmatically with parseOnLoad set to false:
- Set “dojoDndItem” as the CSS class name for each element that should be draggable.
- Use javascript to create a dojo.dnd.Source object for each parent container object. These items should be direct parents fo the draggable elements.
While this allowed all of the portlets to be draggable, I found that none of the form text fields or other interactive elements in the portlets worked. We need drag handles! As it turns out, specifying a parameter of “withHandles: true” in the Source object, and then giving an element a CSS class of “dojoDndHandle” allows only part of the draggable object to function as a drag handle.
The finished result looks like the following:
Posted in Javascript | No Comments »
Tuesday, February 5th, 2008
After adding our new Google Maps and Search portlets to the Yale portal, I was disappointed to find that the page load times for our portal took a noticeable hit. It appears as though merely including the javascript for the maps and search APIs is enough to degrade performance, even if you don’t *use* the APIs. As much as I adore the shininess Google has bestowed upon the internet, that kind of performance hit isn’t always acceptable. In the portal’s case, we were even less able to overlook these load-time issues, since these portlets are generally rendered on every request, but users don’t necessarily use them each time the page is loaded.
I initially decided to write javascript to only include the Google javascript on demand. In this model, we wouldn’t include the external script in the top of the page. When the user tried to interact with the portlet for the first time, we’d import the Google javascript, then perform the user’s request. This approach causes the user’s first interaction with the Google elements to be slower that it otherwise would, but at least the user only has to wait for the Google scripts to load when he or she actually wants to use them.
As nice as this plan was, I discovered that Google’s scripts include other scripts via document.write. In practice, this means that if you attempt to load the Google javascript libraries on demand, the page reloads and then hangs. 
The solution I ultimately used was to isolate all the Google content in an IFRAME and only load the IFRAME when the user attempts to perform a Google-related action. Initially, the page contains a search form and a dummy IFRAME with no src attribute. When the user performs the first search, the javascript switches the IFRAME to include a small google AJAX search page with the appropriate query. As the frame is loaded, javascript sets the IFRAME element height to the height of the enclosed page, so the user never sees any scrollbars. For the Google Map search, we followed a similar approach, replacing the initial map view with a simple image.
above: A Google AJAX search loading in an IFRAME.
Posted in uPortal, Javascript | No Comments »