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.
Posted in Java, uPortal, Calendar Portlet | No Comments »
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.
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.
Posted in Java, uPortal | 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 »