Loginskip to content

Archive for February, 2008

Programmatic Dojo Drag and Drop

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:

  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:

Calendar Portlet Released

Thursday, February 7th, 2008

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.

Feedback Portlet Released

Thursday, February 7th, 2008

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.

Feedback Portlet Administrative View

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.

Google Maps Search Plugin

Tuesday, February 5th, 2008

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

Google APIs and Performance

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.

A Google AJAX search loading in an IFRAME.
above: A Google AJAX search loading in an IFRAME.



Categories