Examples of Channel Types

Kim Ditloff prepares and presents training here at Unicon and is preparing an updated training offering on managing uPortal. She's asked me to prepare some real-world examples of the various channel types in uPortal. I'll post these here in the spirit of openness, but you should still sign up for her training at least once to get a dose of this and oodles of other interesting uPortal knowledge.

Custom Channels
The "Custom" channel type allows for the most general and generic configuration of channels. You can configure traditional channel types in novel ways, e.g. to invoke the more arcane configurations of CWebProxy. The custom channel type is also more commonly used to configure entirely new, institution-local channels, as well as the sorts of channels you might grab from the JA-SIG opensource community. The uPortal Announcements Channel is typically configured as an instance of the Custom Channel type.

Applet Channels
The Applet channel type eases configuration of channels presenting Java Applets. This used to be a popular way of delivering rich interactive widgets but has fallen by the wayside as other approaches fill this niche. Java Applets are sometimes problematic for reasons of diversity of end user browser and Java runtime environments. In any case, if you had an instance of the Mindterm Java Applet shell or perhaps a course-specific graphing applet, you could present it in your portal using this channel type. I suppose a portal administrator might find it convenient to have a tab with a shell built right in, perhaps alongside some channels presenting portal status or metrics, so that he or she can access the web from home and shell in to examine logs right through the web browser.

Image
The Image channel type simply presents an image specified by URL. You can use this to present a campus picture of the day (supposing you have some external process to cause a new picture to be served from that URL each day, e.g. a batch job.) This channel is also a fine way to present graphs from such tools as Webalizer. If you have a tool that's computing metrics about your portal, and you'd like to see those graphs right in your portal's administrative layout, (and those graphs are publicly available, or at least available to your browser), then this channel is a quick, easy way to get the job done. If you're working technical support and have interesting metrics that result in graphs, that too would make fine image channels.

Inline Frame
Inline frames have a lot of downsides. They're also really simple and work very well, bringing along the styling, allowing the browser to perform the work of aggregation. They're sometimes appropriate. This channel simply allows you to IFrame some URL. It's commonly used to put a whole application onto a tab as the body of the tab. If you've got a webmail application, you could have a webmail tab and on that tab could be an inline frame channel to that application. Personally, I never find this worthwhile. I think this channel works best when you can know ahead of time the dimensions of the content to be framed so you can give it an appropriate size and avoid those ugly scroll bars. Inline frames are often used to present custom applications via the portal even though they are hosted elsewhere.

Portlet
The JSR-168 channel type is needed whenever you'd like to present a JSR-168 portlet via uPortal. Interesting JSR-168s you might want to use include the UW Web Proxy Portlet and the portlet views of Hypercontent, JForum, Alfresco. JSR-168 portlets can be thought of as the standardsy version of the custom channel approach.

RSS
Really Simple Syndication is used for all sorts of things and so this channel can be employed to present campus blogs, portal developer blogs, topical feeds from Google News, campus newspapers, and the like.

Web Proxy
CWebProxy is a versatile generic proxy channel and a mechanism for presenting custom web applications via your portal without running additional code in the portal server's JVM. It will happily proxy static web pages or entire web applications written in whatever language you're comfortable with. YaleInfo uses CWebProxy to present their network registration application via the portal. CWebProxy allows you to write custom applications for the portal without writing IChannels or JSR-168 portlets.

Increasingly, JavaScript snippets are popping up all over the web to present interesting little badges, such as latest images from Flickr, opensource project code metrics, even progress on goals. You can easily include these in a uPortal instance by pasting the snippet into a file accessible to the web (or local on the portal filesystem with some extra configuration) and the configuring a CWebProxy instance to proxy that file.

Channels such as campus user directory search are typically implemented as web proxies to custom applications.

CWebProxy is the topic of a previous blog post and will likely be the topic of many more in the future.

WRSP Consumer
Frankly, uPortal's WSRP Consumer is not very robust, but it can be made to work for some problems, as demonstrated by Vishal Gupta's heroics on exposing Sakai Tools via WSRP, the CREE project's work in presenting library portlets via WSRP. PeopleSoft now exposes WSRP suitable for consumption in a campus portal. WSRP can be thought of as the standardsy version of the CWebProxy approach.

XML SSL
This channel type allows you to specify a URL to an XML document to be transformed using an XSLT stylesheet selected by a .ssl (stylesheet selector) file. This is one of the most versatile and useful channels in uPortal. Whatever content you're looking to provide, it can be modeled as XML. Upcoming events, announcements, news, reminders, to do items, requirements, opportunities, deadlines -- whatever it is, it can be represented using XML, either via a standard existing schema or a new one made up for the occasion. Once you've got some XML, a web developer composes an XSLT suitable for rendering that XML, perhaps more than one if you're looking to vary the presentation across browsers (per the stylesheet selector). This channel will pull the XML, transform it via the XSLT, and display it as the channel body, subject to configurable caching.

This means that applications, departments, content providers to your portal can host their content remotely. They can edit it however they're comfortable - via a GUI tool, via a text editor, as an output feed from a web application, whatever works. And then your portal can present it. Whatever custom code need exist, it can run elsewhere than in the portal.

For example, if you have a custom course management system, and that system can be made to expose an XML feed of courses for a student, you can configure an XML SSL channel to pull that feed, transform it, and present a quick list of the student's courses with just as much rich context as your course management system cares to expose via XML.

Exposing feeds like this introduces security concerns, of course, concerns that are neatly solved using CAS proxy ticket technology.

XML XSLT
Stylesheet selectors are very powerful things, allowing you to select different XSLTs for rendering across different browsers, and as extended in uPortal, even select different XSLTs for internationalization purposes. They are, however, a pain in the case where you don't have these needs. Instead of writing a .ssl file to select exactly one XSLT, you can simply write the XSLT and specify its path directly via this channel.