Long Time No Blog

To anyone who missed out on uPortal thoughts being posted here over the last month, I apologize. I've been creating content on Unicon's new support website and so have been distracted from keeping this space up to date. I do appreciate Blogspot's hosting blogs here at Blogger/Blogspot, and I suspect someday I'll be back here blogging along, but now I'm trying to draw eyeballs to Unicon's exciting new support website, so my blogging is currently happening there.

Here are some teasers for recent blog posts available on the new site:

• I start with the obligatory meta-discussion of blogging and of the new website. (It's interesting, my cube-mate on the Sakai side of things dived right in with discussion of term-based site filtering in Sakai. I'm occasionally accused of being insufficiently technical and there's probably some truth to it.)


• I've started a series of blog posts on favorite uPortal features. So far I've covered addressing channels by functional name and pluggable error channel rendering.


• There is a post discussing the provisioning and use of channel controls.


• Another post motivates why your campus desperately needs a portal anyway.


• And CWebProxy is a favorite uPortal feature in a class all its own, so it rated its own blog post.

Please, drop by, read what you may find useful, and feel free to avail yourself of the commenting feature to let me know what you think, tell me to be more technical, or more generally guide what kind of posts would be welcome.

Wanted: uPortal and/or Sakai developer

My employer is hiring for a uPortal/Sakai developer position. If you are a uPortal or Sakai developer, take a look at the job posting.

Compelling Unauthenticated uPortal guest layouts

I've posted the PowerPoint slides from my JA-SIG Atlanta 2006 talk on compelling unauthenticated uPortal user experiences. I took some pains to thoroughly annotate each slide, and I hope this results in their being more helpful to folks who couldn't make it to the conference.

IChannel or JSR-168

(Reposted, edited, from something I wrote on the jasig-portal list).

Should I write an IChannel or a JSR-168 portlet?

You should do whatever makes the most sense for whatever it is you're trying
to accomplish. Which is a fairly generic meaningless thing to say, but I
think it's the truth.

If you care about cross-portal, if you're building the portlet to end all
portlets and you want to run it anywhere, if you want to run it in uPortal
3, if you're building something sufficiently generic that you'll want to
share it with or collaborate on it with folks using other portals, if you're
looking to use JSP or some other templating technology other than XSLT, if
you're looking to maximize the re-usability and value of your learning
investment, or if you're looking to take advantage of an excellent MVC
framework (Spring PortletMVC), then JSR-168 can be a good choice.

If you're writing a quick one-off, a throwaway channel, something that will
run afoul of known uPortal JSR-168 support eccentricities (bugs?), then
IChannel can be a good choice. IChannels can better implement
unauthenticated portal page use cases and multiply subscribable widget use
cases. IChannels can incur less configuration pain, being multiply
publishable via the uPortal UI rather than requiring portlet.xml files.
JSR-168 portlets typically incur an additional web application on your
server, and get their own classloader, which is really neat isolation unless
it isn't that neat because it's getting in the way of something you want to
do, like share services between portal and portlet. And sure, you can solve
this via putting services in shared classloader locations etc., but it can
get complex. Channels have a few neat tricks up their sleeves, such as
ability to register IPermissibles with the PermissionsManager and delegate
to the GroupsManager and PermissionsManager servant channels. For specific
use cases where this accomplishes your goal, this can be pretty neat.

And often, a good choice is to write neither, and instead host the
applications or content remotely from the portal and use a web proxy
(CWebProxy) to proxy it, thereby keeping the software outside of the running
portal. This can ease the complexities of rolling new versions of the
widgets in your portal into production. With customer JSR-168 or with
custom IChannel this requires coordination with portal server maintenance.
When proxying remotely hosted content, the particular remotely hosted widget
can have independent outages, upgrades, and all that is affected is that one
widget. And, of course, the proxied application could be implemented in PHP
or Ruby on Rails or Spring WebMVC or really whatever is most convenient.
Judicious use of proxies can also reduce load on your portal server itself.

Which of these options is the "right" answer in any given case depends. I
don't think you get any bonus points for doing JSR-168 where it doesn't
actually buy you anything you want. However, there are some significant
advantages of JSR-168 *if* they are advantages for the particular problem
you're solving.

Atlanta JA-SIG Conference Calendars

I've created Google Calendars representing the Pre-conference seminars, Birds of a Feather sessions, plenary sessions, kiosks, mini seminars, the Projects Applications and Solutions track, and the technical development track. (All of these links are to add the calendars to your calendar, and none open in new windows, so right-click.)

This was pursuant to my figuring out what I'm going to attend at the conference.

uPortal is popular

According to Yahoo Site Search, there are 4,479 pages on the web that link to uPortal's main webpage. 4,450, I suppose, once this blog post is indexed.

That sounds pretty darn popular to me.

What does this mean? Well, Yahoo Site Explorer credits Sakai's main webpage with a comparable 4,653 inlinks.

Your campus needs a portal

Sometimes people ask me why a higher education campus needs a portal. Financials software, learning management systems, the value proposition is more tangible. But a portal? A meta-application that itself doesn't do much? Why do I need that?

Here's the relevant problem universities have: they're complex, there's a lot going on, there's a lot of noise, there are all sorts of services dribbling all over the place. This is a source of stress. People miss opportunities. How many people wish they could go back to college and take one more class, attend one more guest speaker, get just a little more involved in some activity? I bet basically 100% of college graduates.

Those are the opportunities JA-SIG software helps people realize. Because by virtue of the Central Authentication Service) you spend less time mucking around with lots of different accounts or having your online identity stolen you're less stressed and more able to take advantage of university. Because the portal helps you to be aware of events and requirements and opportunities, you're able to plan more effectively and better use your time. Sakai as learning and collaboration system facilitates doing the real work of learning.

Colleges need to be on opensource because life is too short for artificial constraints, for a vendor telling you what you are and are not allowed to do. Opensource frees colleges to go after the services and integrations that will actually deliver value to their constituents, or at least help the technology get out of the way as much as possible, and it is that that will make the educational experience better. It frees them to choose the locally-appropriate spot on the edginess curve, whether they want to be very conservative and limit risk or want to be on the edge with lots of cutting edge code.

Enterprise portals are for "members" of the University community. Who play lots of different roles and have many different activities and needs. They are sometimes very serious and studious. They are sometimes playful. They are sometimes collaborating in ad-hoc groups. And sometimes they're just trying to navigate bureaucracy. uPortal and Sakai are flexible enough to accommodate all of these roles and behaviors: uPortal is all about gathering user attributes and using them to understand groups and roles and to provide appropriate content. It's all about aggregating relevant information to help someone stay on top of the game. And Sakai is both a relatively serious pedagogically-driven LMS and a platform for more adhoc collaboration. In addition to offering course-related sites, you can create sites in Sakai for various groups on campus to collaborate outside of the context of courses.

The software is complex but that's because it's modeling a university that is necessarily complex. This is complexity that is doing work.

Getting portal groups and user attributes to portlets

The package esup-portal-ws provides a web service to retrieve uPortal group and user information from portlets.

This looks like an alternative to the classloader games we sometimes play.

In the words of Pascal Aubry (as posted to jasig-portal):

One of the main issues we encountered when developing portlets is that the portal and the portlets run in different Tomcat contexts, which prevents from accessing the portal objects from the portlets, in particular, the groups and the user attributes (Note: hopefully this separation has many advantages).
The package esup-portal-ws solves this issue by providing a web service (executed by uPortal and interrogated by the portlets) which gives access to the portal groups and user attributes. We think that this project can be useful for the whole JA-SIG community, especially the people who develop portlets or port existing uPortal channels to portlets, and who want to keep a close integration between their portlets and the portal Information System.