How to make the varsity team

Sadly, uPortal didn't make this list of recommended portals. Why? Well, the categories of recommendation are a little elucidating. uPortal needs to be better at:

1. Ease of installation


2. Number and usefulness of included portlets


3. Extensibility of architecture

I would have thought that uPortal was already way ahead on "extensibility of architecture", with XSLT templating technology, exceptionally powerful groups and permissions, an excellent and pluggable DLM layout manager, and ever increasing Springy declarative configuration, with a rosy expected future of all-Spring-all-the-time in uPortal 3, Peter's highly pluggable rendering pipeline, and Mark's pointedly pluggable parameter processing pipeline for the next rev of DLM. And of course pluggable error rendering, still one of my favorite features ever. Awareness of the extensibility of uPortal is less than it ought to be and there are things we could do in the documentation and web presence to raise awareness of the uPortal strengths.

Far to go and much to learn. But uPortal is still an excellent portal as is and I would have liked to have seen it make the list.

How UE designers can help with uPortal

Someone recently emailed me to ask about getting involved with uPortal. I answer here in the interest of transparency and getting word out that your involvement is welcome.

Hi, I'm a Graphic Designer/Developer. I currently create Web Based Training for [a large organization]. I came across uPortal and noted the need for UE designers. I would like to know more about what the project needs and see if I can help at all.

Welcome! I'm sure you can help.

The case for englightened self interest:

I'll address the question of what the project needs, but let me first articulate this: the project needs what you need. We're not looking for martyrs to do a lot of work out of the goodness of their hearts (any would-be martyrs are welcome, but you're not what we're building this project on). What is needed, what is sustainable and what works, is for people to do work that makes sense from their own perspective.

It's a matter of a community of collaborators acting under an approach of enlightened self-interest, rather than a centrally organized commune.

So, for instance, you might need a portal. And you might need that portal to not look brown and drab, you might need it to support drag and drop user experiences for portal customization, you might need it to use nested divs instead of nested tables, and you might need it to support interesting ajax callbacks. Or maybe you just need it to have a little spiffier documentation. It turns out, there are lots of other people who need these things too. And if you speak up on the list and find some of them, they may be available to collaborate and help design/work on/QA these enhancements. Or you may develop them all on your own but then seek to re-integrate them with the core uPortal so that others will help maintain them and you'll experience a lower total cost of ownership of your portal.

Or maybe you don't immediately need a portal, but you're looking for some interesting projects and an opportunity to collaborate with the smart, fun, and good-looking JA-SIG community. It's a little harder to tell collaboration stories that work when you're not looking to yourself put the portal into production, but this can work.

So, as you read through some descriptions of what uPortal needs, be sure to think about what you need, what needs you think are shared between you and other uPortal deployers, because really, uPortal doesn't need from you anything more than the intersection of what you need and what our current and would-be deployers need.

What uPortal needs from User Experience developers:

uPortal needs a more attractive out of the box skin. Jason Shao and others have worked on this for uPortal 2.6 (the current HEAD of the portal CVS project) -- that work needs engagement and validation by additional developers and the issue of whether and what to do about the default skin in uPortal 2.5 is certainly still open for discussion. For the right skin, I think it absolutely would be worth the pain of a skin upgrade in the patches branch. A modern skin would improve the marketabilty of uPortal.

uPortal needs more attractive optional additional example skins, ideally with good instructions and an easy migration path to turn them on. More showcasing of what can be done with uPortal.

uPortal needs to close the gap between DLM and ALM and SLM theme transforms and more generally improve the pluggability and re-usability of skins. It would be oh so awesome if skins were modularized such that we could just pass them around, at least for the 80% most modest theme transform needs. There will always be the opportunity for advanced hacks to produce cooler user experiences, and that's a good thing, but the majority of sites should be able to settle on a common set of user experience functionality and share neat skins.

uPortal needs more and better how-tos and documentation for producing these awesome skins. It needs UE people to come to our conferences and developer meetings en-masse and form a more visible and active presence in our community.

The uPortal project itself needs improvements to its web presence, and there's a jasig-webpresence email list for discussing and working on just this topic. We need User Experience exports to join in those dicussions and pick up some of that work. What would a compelling and inviting developer.ja-sig.org homepage look like? While I appreciate the efforts of those who have set up what we've got, what we've got isn't it. We need User Experience experts to help us make our Wiki more usable and our website more compelling.

We have a new and growing process for accumulating, prioritizing, and matchmaking around requirements, and we need articulate, thoughtful, excellent User Experience requirements to go into that process. Yes, we all know we need Drag and Drop. Now what does it really look like? How does it feel? What really neat user experience stories could go into this process that would get people excited?

And in the meantime, are there pokey corners we can easily round to ease the user experience of our product? We need bugs fixed and minor enhancement requests worked on, and while many of the bugs are Java bugs that require java developers, some of them can be addressed in XSLT, which is sometimes the domain of UE developers, and many of the issues could benefit by the input of UE designers to ensure that what is produced is not only functionally complete but also usable.

One of the tragedies of our project is that we standardized on a layout manager that fails to showcase some of our best features. User experience designer input could have brought about implementing a UI for configuring those pesky restrictions and prioritizations of fragments, for subscribe time parameter value solicitation from end users. Let's not make that mistake again: user experience experts can help the project put its best foot forward in showing off the powerful capabilities that lie beneath.

We need user experience input and work both in uPortal 2 and in uPortal 3.

But mostly, we need what you user experience designers need: a flexible and powerful portal platform in which the shared problems are solved via collaboration and the extension points and support is there for you to fly free in solving your local problems and adding your branding and local value-add. We need your help to be the portal that you love to use. And you need to help because you'll love to have a better portal.

A reminder that uPortal is best discussed on the uPortal project lists:

While I try to be available off-list and politely and usefully answer questions sent my way (trying to get better at this), really the very best place to discuss uPortal is on the project lists. We have a list jasig-portal for general discussion of using uPortal, and a list jasig-dev for discussion of active development on the uPortal project itself. We also have a cluster of fringe lists for discussing user expereince, the JA-SIG web presence, uPortal 3 as it exists in the sandbox, and JA-SIG operational issues. If there's a niche for discussion that we don't yet have a list for, let's make one and start discussing and building an archive that can be valuable to others even after the discussions conclude.

While off-list discussions are often useful, they are a tool to be soberly considered because they often miss opportunities for wider involvement, transparency, and archival for future interest.

Power law of participation

The Power Law of Participation provides context to describe what we're trying to do in JA-SIG, and for describing our challenges. How do we make the shallow end of the curve less steep, and better enable casual participation? How do we make it attractive to draw further up the curve into more active participation?

Injecting Spring managed beans into IChannels

Someone wrote me to ask my thoughts on injecting Spring-managed beans into IChannels. This is what I had to say.

I've been playing with using your PortalApplicationContextFacade to acquire Singleton Beanfactory references to acquire Spring Managed beans implementing middle tier operations into my channels. Thoughts?

It's an approach. Channels are tightly coupled to uPortal anyway, so being tightly coupled to the context façade and looking up magic beans by name isn't the end of the world. This approach has the advantage of feeling a lot like our crufty static services invocation approach to life -- the Lookup (anti-)pattern.

Is there a better way?

I'm very attracted to going a step further and using ChannelToBeanProxy where the proxy IChannel looks up a named IChannel bean from the PortalApplicationContextFacade. Then you can wire in your Spring-managed beans to the channel, potentially wire in different service realizations or different proxies on top of services into different channels, etc. Gets a little closer to dependency injection.


Whether you inject into a Spring-managed IChannel instance or you write an IChannel that looks up the beanfactory and beans it needs probably isn't that different, though.

I've been digging for a way to get a startup contextListener to bootstrap the singleton beanfactory and maybe use the factory facilities to have it manufacture beans from the same context in both Spring managed and static contexts, but just thinking about it is so ugly...

It's not that ugly, and we really need to get there. Step one was what we did. Next step is to really buy Spring, use a Spring-provided context listener to bootstrap, and then use a uPortal-provided secondary context listener to expose that Spring-created application context behind the PortalApplicationContextFacade, and this *just doesn't work* outside the context of a running uPortal in a servlet container. Let's get firm about that: that what we're writing is objects and services that run in a running portal, and anything else (Ant tasks?) doesn't belong in the same source tree and can't use these services that legitimately only exist in a running portal except by remoting to the portal. And then go after building and wiring and configuring the services that those components will use -- I don't object to their existing, but it's a serious problem that they basically "happen to work" in the current implementation based on classpath magic and rdbm.properties happening to be in the right place. So, concretely, if you declare a Spring bean that depends on JNDI, and an ant task runs and touches something that touches the PortalApplicationContextFacade, it blows up because the JNDI lookup fails outside the context of the portal running in a container. Which exposes a deeper design problem of running portals and outside the portal tasks trying to use the same services and configuration. A recipe for complexity.

So we drop the requirement of running outside a servlet container. We re-approach those problems and come up with things that intentionally work outside the container, either by having their own configuration or their remoting to a live portal or their using services explicitly designed for that context or whatever it's going to be. Write the uPortal-user-provisioning-tool-as-Eclipse-plugin. But if it touches PersonDirectory, have it do so be deliberately and be very sure how that is going to be configured is worked out.

In the servlet container, we embrace being in the servlet container. Install and rely on that context listener from Spring.

Okay. That was step two.



But we really need to get to step three, which is not only using the Spring context listener, but also using Spring WebMVC. Slam everything we got into a couple controllers, fine. But open up that potential for adding more parallel controllers, for starting to use Spring WebMVC error handling, slapping interceptors and aspects in.

Peter's rendering pipeline plugability and so forth for uP3 is great. But I want it crunched into a Spring controller.



Now I'm out of steps and just observing:

Firstly, uPortal's channel manager really wants to be a Spring bean container. ChannelToBeanProxy is cute and I'm convinced it's useful, but I think it just exposes a deeper realization that ChannelManager should be implemented in terms of a bean container. Channels are beans. The get their configuration wired in. But get them from a bean container that's able to differentiate prototypes from singletons and wire in richer dependencies and apply aspects and so forth. What we've proven with all those static factories and portal.properties properties is that we need to configurably wire services into channels.

Has anyone written the RBDMS-backed bean container?



Second, as cool as it is to wire services into channels, wouldn't you much rather be writing a portlet and use Spring PortletMVC? Wiring dependencies into channels only gets you so far, you're still stuck with the lack of compelling MVC framework and pluggable view technologies for channels. So we keep reinventing it. CWebmail has IXmlMethod. Other channels do other things. Over and over we re-implement grabbing parameters from static data and runtime data. I've kicked around the idea of writing Spring uPortalChannelMvc, which would look a whole lot like Spring PortletMVC except work for channels, binding runtime data to command objects, doing the validation thing, bringing in pluggable vie technology. My thought was that it would be great fun and ultimately low value because I should just give up and write Spring PortletMVC portlets.



The most important, transformative feature of uPortal 3 is pervasive Springiness, and while you can be better or worse at teasing out those extension points and defining good interfaces, more or less you can't help but produce a pluggable architecture if you use Spring properly, and it is this sustainably pluggable architecture that will be the single greatest contribution of uPortal 3. Let's really go after open-closed in the context of uPortal the way Scott has in CAS.

JSR-168 and JSR-286 are uninteresting from the perspective of JA-SIG. They don't matter. Don't go write a JSR-168, and don't worry about what features will be in JSR-286. These standards are the necessary evil that makes frameworks like Spring PortletMVC possible, and once that's possible, the productive thing is to jump on that. What we should all be doing is taking a look at Eric's Bookmarks portlet, articulating what extension points it needs to be an asset to MyRutgers, to Academus, to MyWisc. And then going after the open-closed core that works for everyone and local plugins that make us happy. And that's all about Spring PortletMVC and a domain model and good interfaces, and has very little to do with JSR-168.

JSR-168 is better than IChannel because it gets you to Spring PortletMVC. JSR-286 will be valuable only inasmuch as it allows SpringPortletMVC to be better. I'm interested in what I can do with PortletMVC and the opportunities it gives us to share controllers. I'm not interested in 286 for its own sake since the most productive thing to do is to jump on the PortletMVC framework.


I see the value of injecting spring resources into IChannels as allowing incremental decoupling and Springification of channels, allowing you to demonstrate incremental value or at least progress. The natural outcome is an eventual realization that all that's left in the channel is controllerish stuff, that all the services and domain have been extracted. But then the next step is to move the service and domain into a Spring PortletMVC portlet and re-implement the controller in that richer environment, continuing to realize incremental value in terms of not being forced to use XSLT as the view layer, etc. etc.

Messy Desktop and the Ajax enabled portal

This video talks about organizing documents, but of course the same kinds of techniques can (and should) could be applied to interacting with portlets.

Getting beyond tabs and columns. Way beyond.

Re-using an existing web application as a Sakai tool

Another step closer to being able to drop in an existing web application as a Sakai tool. This feels a lot like uPortal's CWebProxy.

Sakai emblem

A truly beautiful Sakai emblem out of ASU: