Visions of Channels Dancing Through my Head

In the last few weeks we have had some important milestones occur inside our campus Portal. These milestones lay the groundwork for what things we can do in the future:

I rolled up my sleeves, and jumped into Jakarta’s HTTPClient. This is a replacement for our existing proxy server file which had some serious limitations. In our previous proxy server, we had no way to deal with cookies, headers, methods or mime types. All of these things are needed to have a transparent proxy server. HTTPClient can do all of these things, and more with ease. This significantly cuts down on code complexity in external channels.

We now know who is currently logged into the Portal in our external applications. The built in functionality for doing this was utterly broken and we were left to find another way. After much experimentation, we developed a working solution of setting the user’s uid and username in a session cookie accessible to the “.clayton.edu” subdomain. Now any application we develop can access this information, and provide truly meaningful content. We now have a channel that shows a faculty member their course survey statistics.

Figuring out how to convert postbacks to partial updates (via AJAX)  inside channels took a while to iron out. Javascript’s same-origin restrictions made this solution only as good as our proxy server (which just had a steroid shot in the arm). Languages like C# that try to take care of the magic of AJAX for you behind the scenes fail to deliver. We needed languages that provided the control and transparency of converting full postback requests to AJAX calls. Thanks to Rails and a few extensions, this is fairly straight-forward, even when routing through a proxy server.

Static HTML is the worst thing a channel can contain. It may look pretty, but these are “dead channels“, because the content never changes. Because it never changes, it isn’t interesting on subsequent visits. My goal is converting nearly all channels from static to dynamic content to have a truly alive Portal. This means consuming RSS feeds, pulling info from databases, LDAP, etc. Recently, I have deployed an in-house RSS feed reader, and I have adapted the “Academic Calendar”, and “HUB Knowledgebase” channels to use it.

A few channels down, hundreds more to go. Moving to dynamic channels would be fairly easy, except hat probably 90% of our external website’s information exists only in static HTML files. This has to migrate into a CMS, and I see this as being the next hurdle. I have a fairly good idea of what needs to be done to make a CMS integrate into the Portal, and campus website, and the barrier now is getting the time, resources, and blessing to tackle such an undertaking.