uPortal Vision and Roadmap (All Versions)

This page attempts to detail the current visions and roadmap for future major versions of uPortal. This is an evolving document. The current uPortal Releases document may also be of interest.

uPortal 3.2

Vision: End-of-maintenance has passed.  Adopters should upgrade to latest uPortal 4.0.x for a stable release or to the in-flight code towards uPortal 4.1 for an aggressive, cutting edge release.

Current Status: Maintenance branch exists but is no longer maintained; maintenance branch.

uPortal 4.0

Vision: uPortal 4.0 is the maintenance branch for the previous release series.  It is increasingly conservative.  Adopters are urged to upgrade to 4.1.x where active maintenance development can better continue.

Current Status: Maintenance (fixing bugs); maintenance branch.

uPortal 4.1

Vision: uPortal 4.1 is the stable, conservative, active maintenance branch.  Adopters seeking a stable version should upgrade to or adopt the latest 4.1.x patch release.

Current Status: Maintenance (fixing bugs and adding backwards-compatible improvements and new features).  Maintenance development in rel-4-0-patches.

uPortal 4.2

Vision: Continuing the effort to replace legacy code, improve performance and reduce configuration overhead 

Current Status: In development in master branch.

Wishlist

A list of possible uPortal projects for future development:

Integrated, Modern Content Management System

uPortal currently includes a simple content management portlet. This enables publishing of rudimentary, static content. While this is useful, new and existing adopters have come to expect more functionality when it comes to adding static content to the portal. We propose developing  a more full-featured CMS implemented as an integrated suite of portlets. Features could include:

• Configurable Content Types

• Configurable Taxonomy

• Configurable Views

• Reviewer Workflow

• Delegated Administration

• Media File Management

This suite of tools would allow portal administrators to more effectively engage others in the creation and curation of content within the portal.

Transient layouts for the guest user

Enhance uPortal to allow transient layouts for the guest user.

(Andrew Petro wonders why?)

(Andrew Wills hopes he can explain:  There are many circumstances where we'd like to bring an unauthenticated user to a specific piece of portal content that may not be in the guest user's layout.  The "Reset My Password Please I Forgot It" portlet is a good example.  Specific announcements or notices are another.  Often clients would like to send a link in a email that takes the user directly to the content.)

Separate uPortal-core from uPortal-heavy

Separate uportal-core and uportal-heavy projects.  uportal-core would be current uportal pared down as much as possible (framework and framework portlets only, bare bones default data).  uportal-heavy would depend/overlay on uportal-core and add example portlets, make exciting cutting edge features on by default sooner, etc.  Would resolve some tension between optimizing uPortal open source deliverable artifacts for overlaying upon locally vs suitability for forking from or demoing.  uportal-core becomes a bit more conservative, and perhaps uportal-heavy becomes a bit more exciting.  We get to an architecture where it is more possible to define multiple overlays over uportal-core for different purposes (SSP?  Stable demo?  Bleeding edge demo?  Could be three separate overlays if it's worth making the distinction!)  Everyone wins.  Can probably think of a better name than "uportal-heavy".

Embed Grouper

Embed grouper.  Shed a bunch of uPortal-specific groups and permissions code.  Do this in such a way that embedded grouper plays nicely with enterprise external grouper where available.

Framework Support for Portlet Interaction not Triggering Page Refresh

Currently clicking any portletURL in a portlet triggers a full browser https:// request-response cycle against the portal server, with the user having to wait for the page to re-render.  Instead intercept these clicks, translate them into AJAX requests, and monkey-patch the portlet div with the new content inline.  This is probably only appropriate for renderURLs, or at least it would be easiest to start there since they're supposed to be lowest-side-effect.

This would improve the perceived snappiness of some kinds of uPortal interactions without individual portlets having to build in their own AJAX capabilities.

Framework support for asynchronous rendering of portlets

Currently rendering the portal page waits for the render completion, server-side, of each portlet (or the timeout of that portlet's render job).  

Instead (sometimes?  for slow-rendering portlets?) the portal would render down to the browser the JavaScript snippet(s) that would then pull down the markup for the portlet renders and monkey-punch them into the portlet divs when the markup is available.  This could yield a perceived snappier experience for end users.

Some portlets individually implement asynchronous rendering such that what is rendered to the browser is JavaScript that then pulls markup from e.g. a resourceURL.  This framework capability would make engineering that feature into individual portlets on a one-off basis less necessary.

Gradle-based Build System

We could make the uPortal build and the shell-based admin functions a lot more sane by moving to Gradle.  We would also speed it up significantly – by as much as an order of magnitude.