Jasig/uPortal — pull request #262 by apetro (2014-03-10 19:58:16+00:00)
Title: Add special UI for zero-favorites case, other Favorites UI cleanup.

Also implements link to Marketplace, with configuration of Marketplace `fname` in `portal.properties`, with graceful degradation when not so configured.
Also externalizes most messages to message bundle.

## Features

### Un-favoriting your last favorite

The EDIT mode now has a special view for the results-in-zero-favorites case:

![un-favorited-last-favorite](https://f.cloud.github.com/assets/952283/2363465/4a9070d0-a64e-11e3-83be-3dd215ee914e.png)

### Viewing Favorites with no favorites

If you are in that have-no-favorites state when you walk up to the portlet in VIEW mode, you get a special have-no-favorites VIEW mode view:

![no-favorites-view](https://f.cloud.github.com/assets/952283/2363475/6c4f3a08-a64e-11e3-8184-dbd35761b55a.png)

### Links to Marketplace, with graceful degradation

The fname of the desired Marketplace portlet is now configured in `portal.properties`. Favorites is intended to complement Marketplace, with Marketplace being the catalog of things you might Favorite. However, these complementary features are in development in parallel feature branches, ensuring that they are independent enough that they can be adopted independently.

This fname-via-configuration-in-`portal.properties` allows Favorites to not binary depend on Marketplace classes.

When the Marketplace fname is configured in `portal.properties`, UI links to Marketplace, e.g.

![no-favorites-view-marketplace-linked](https://f.cloud.github.com/assets/952283/2363489/b88f6ce4-a64e-11e3-9f61-2c5c1f56f4c9.png)

![no-favorites-edit-marketplace-linked](https://f.cloud.github.com/assets/952283/2363490/bc74f5d6-a64e-11e3-8f67-cc61a3e8a7da.png)

Note that the "Find Apps" in these screenshots is a UW-ism since these screenshots were taken from in-flight re-designed UW Madison portal -- the default Message bundle as implemented here for Jasig doesn't call portlets "Apps".

### Messages moved to message bundles

Messages are now in resource bundle, so you can achieve this kind of hipness without editing any Java or JSPs:

![message-bundles-yo](https://f.cloud.github.com/assets/952283/2363460/335177e8-a64e-11e3-9805-c41c644ba958.png)

## Technical Debt and Deferred Opportunities

* Dynamic success and failure messages generated on un-favoriting a favorite are not in the message bundle. It would be nice to get them there, conveying a message code and possibly also the dynamic title-of-affected-favorite via render parameters from the Action handling the delete and the immediately following Render rendering the resulting UI, rather than the current clumsy implementation of shoving the whole message into a render parameter (which shows up in the user-facing URL. Ugly). Backlogged within My-UW Madison product backlog, but not a priority.
* Adding a favorite while the Favorites Portlet is on the screen does not update that instance of the Favorites portlet to list the favorite. So if, say, you favorite the Favorites portlet, the Favorites portlet favorites listing does not dynamically update to include the new favorite. Technically difficult to solve that, though I suppose the inline favoriting could include detecting whether the favorites portlet is on-screen and if so force a page re-render. This is a tangential edge case, though -- in the real world users won't be adding favorites while the Favorites portlet is on-screen and if they do they're already looking at the now-favorited-thing so they don't need the Favorites portlet to update immediately with a link to the now-favorited-thing, it can wait until the next render.
* This changeset makes Favorites linking to Marketplace conditioned on configuration in `portal.properties`. The portlet could predicate including a non-null marketplace portlet fname on the accessing user having permission to render the portlet referenced by that fname so that portlet would gracefully degrade when configured with bad marketplace portlet fname and also gracefully degrade when the accessing user doesn't have permission to access an otherwise viable configured marketplace. This complexity may not be worth it. Anyway it is not yet implemented, and it is not currently backlogged in the My UW Madison product backlog because the current vision is that all users will have access to Marketplace.