Qwertied

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.

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:

1. Set “dojoDndItem” as the CSS class name for each element that should be draggable.
2. 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:

<script type="text/javascript"> dojo.require(”dojo.dnd.Source”); var c1 = new dojo.dnd.Source(”container1″, {withHandles:true}); var c2 = new dojo.dnd.Source(”container2″, { withHandles: true }); </script></p> <div id="container1"> <div class="dojoDndItem"> <div class="dojoDndHandle">Handle 1</div> <div>Object 1 content</div> </div> <div class="dojoDndItem"> <div class="dojoDndHandle">Handle 2</div> <div>Object 2 content</div> </div> </div> <div id="container2"> <div class="dojoDndItem"> <div class="dojoDndHandle">Handle 3</div> <div>Object 3 content</div> </div> </div> <p>

I’ve added the initial version of Yale’s new Calendar portlet to the JA-SIG source code repository. The portlet aggregates calendar content from multiple sources and displays the resulting events in a simple list view.

The portlet was designed with uPortal in mind, but as it follows the JSR-168 portlet specification, it should be able to be run in other compatible portlet containers.

Features:

• Aggregate calendars and produce a read-only display
• Calendars may be iCal feeds on the web or CAS-proxy protected iCal feeds
• Create custom calendar adapter implementations to retrieve calendar information from databases, custom XML schemas, etc.
• Admins may define default calendars and assign them to users by role
• Users may add additional calendars from iCalShare, Google Calendar, etc.

Technical details:

• JSR-168 portlet
• Spring PortletMVC
• Hibernate
• ical4j

To try out the portlet, download the source code from subversion at https://www.ja-sig.org/svn/portlets/CalendarPortlet/trunk, run “mvn install”, and follow your portal’s instructions for portlet deployment.

Additional screenshots and user-focused help documents can be found at http://www.yale.edu/yaleinfohelp/my-calendar.html.

The initial version of the user feedback portlet developed at the JA-SIG Winter Unconference has been added to the JA-SIG source code repository. The portlet allows users to provide simple feedback about the containing portal, and also provides an administrative view of the content.

The portlet was designed with uPortal in mind, but as it follows the JSR-168 portlet specification, it should work in other compatible portlet containers.

User feedback submission features:

• Simple user UI for comment submission
• Users may make their feedback anonymous, but the default is to collect user information
• Automatically collect information about the user and his or her browser

Administrative feedback features:

• Admin interface for viewing feedback with recent comments and overall stats summaries
• Easily filter feedback by type or user role
• Shortcuts for sending email to non-anonymous users
• Excel data export
• Optional listener to forward feedback submissions on to an email address

Technical implementation:

• JSR-168 portlet using the Spring PortletMVC framework
• Hibernate backend

To try out the portlet, download the source code from subversion at https://www.ja-sig.org/svn/portlets/FeedbackPortlet/trunk, run “mvn install”, and follow your portal’s instructions for portlet deployment.

Search Google Maps a lot? I’ve posted a new Google Maps search plugin for Firefox. You can download it here.

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.

I’ve never been much of one for New Year’s resolutions, but I do need to get a little more organized. Since I’m a mac user, I’ve been trying to get more of my schedule and todo-list into iCal.

I especially wanted recurring todos: a daily reminder to take a vitamin, a monthly checklist of bills to be paid, a weekly note to clean the shower. However, iCal only provides an ability to create recurring events; poor little todos are left out in the cold, dark world of the limited feature set. Luckily for me, an intrepid blogger published his hack to accomplish just this. I’ve edited his script to add the ability to recognize monthly recurring events and to transfer the notes field along with the event. (If you need these features, follow his directions, but use this script instead.) Thanks Alex!

So far iCal todos are working well. The combination of auto-generated regularly occurring items and manually added entries offers the flexibility and automation I wanted. The notes field allows me to elaborate on the steps involved in achieving particular goal, include the phone number of someone I need to contact, or associate all sorts of other useful information with the items. The ultimate selling point of using iCal is of course that I can sync my calendars and todo lists and their associated notes with the iPod nano I already carry around everywhere.

So if you’re looking for me, I’ll be the geek wandering through the grocery store reading my grocery list off my iPod.