I think we can all agree that search is a badly needed feature. This is the best way to locate content, and it sure beats the alternative of clicking through each tab to find something.

My questions regard the implementation of such a search. I suspect the reason that Sungard doesn't offer this feature is because it isn't something that can be quickly / easily tackled.

We have completed this process at Clayton State University, and have felt that it would be best to release our installation documentation to try and help others who are pursuing similar interests. Below is a modified extract of our documentation, as well as sample scripts that can be modified in any way to suite anyone's interests.

UPDATE: Now with 100% more working power in IE 6

We have run into a frustrating problem at Clayton State University - our Portal outgrew 1024x768! We now have 15 tabs in our Portal, and with some names like "Recreation & Wellness", and "Content Cheat Sheet" we found that people were beginning to have a horizontal scroll bar. 

We are moving to Parallel deployment at Clayton State University. This came about as a response to the continuous performance and reliability problems we are experiencing with our Portal.

We have patched to the bleeding edge, at 4.2.1.0 at the time of this writing, and are still experiencing show stopping performance problems. I am curious to know what other institutions are averaging as far as performance goes, and with what settings, hardware specs, etc are being used.

Here is a little about us:

I hate the mouse. It is much slower, and more inexact than using the keyboard in a many cases. When we have to do mouse-heavy operations, like changing a channel's audience, I look for an automated alternative.

When I got hit with having to change eight channel audiences (potentially multiple times), I saw it as a perfect excuse to check out Selenium - an extension for Mozilla Firefox.

Can you get three GCF connectors working in 10 minutes? Don't feel bad - its probably not possible. Restarting the webserver and CPIP systems alone take half that time. What if there were an alternative to GCF that allowed you to produce connectors that this rate? After a brainstorming session, we developed a simple solution that allowed us to do just that.

What is a GCF connector actually doing?

Wouldn't it be nice if your Portal provided some mechanism to lookup who is logged in? Perhaps a domain wide cookie that other application could read? At Clayton State, we have done just that using the iPerson object. Our external channels can read this cookie, verify its contents, and set the user to deliver truly personalized content.

The iPerson object

The iPerson object is a class in Java that we can query to find out information about who is logged into the Portal. Look at the following code:


<%@ page language="java" contentType="text/html" %>

Update: Many of Lumdev folks have already contributed connectors to the SVN repository. You can see the available connectors here

In an effort to avoid duplication, I am proposing that we have a central location to place all working GCF connectors.

We have several in house applications that wouldn't be of any use to distribute the connectors for, but many of our systems are 3rd party enterprise solutions.

Introduction

At Clayton State, we have created a channel that displays the top 5 most recently created, and recently modified channels. During this process we discovered that much of the channel information is stored in LDAP (and thus is why it is so mysterious to find).

Our channel has a few shortcomings, one of which is that all users see the same top 5 newly created, or updated channels, regardless of the channel's audience. This means that if we wanted to honor the Portal's permission ...uh... structure, then we had to do some digging.

Anyone who has looked around on this website (or in certain section of documentation) for any length of time has probably come across nested-tables.xsl. This file is the "starting point" for the portal rendering. XSL works by taking an XML input file (generated from Java services), transforming it, and spitting out HTML as an end product. The result is what you see in your browser after you login to the portal.