Background

There is a client that wants to support large numbers of tenants and have each tenant be able to perform some minimal customization for their particular skin.  At least initially, the customizations are to select a few colors that are unique to their tenant institution to apply to the skin.  Eventually there may be other elements that that the tenant administrators can control. The tenant administrators will be non-developer personnel (secretaries / general school staff) so they need a very simple UI interface for making and applying the changes.

There is a separate but related effort for supporting large numbers of tenants where a 'tenant template' is a set of fragment definitions, fragment layouts, portlet definitions, and other data that are applied (dynamically adjusted and imported) when a uPortal system administrator creates a new tenant.  This tenant creation / deletion process must be a very simple process to create a tenant and have a tenant immediately operational, but also allows the tenant to do basic, minimal customizations to their tenant configuration (again by staff that are non-technical).

Design

One idea for addressing this need is to have a 'Skin manager' that is one of the portlet definitions in the tenant template and allows the tenant administrator to configure their tenant's skin / color scheme.  As a design simplification, the skin manager uses CONFIG mode to allow the tenant administrator to configure portlet preference values that are applied to the 'template skin'.  The tenant's fragment layouts (from the tenant template) include the Skin Manager portlet instance in the preHeader region to apply the template to authenticated users (and possibly guest users though this requires a scheme such as a servlet filter to identify the appropriate tenant based on URL parameters or similar).  The skin manager rendering in non CONFIG mode is responsible for rendering whatever content is necessary to render the tenant's skin appropriately.  

Design goals:

• Simplified design that fit within client's budgetary constraints, but can be used as a base for more dynamic and feature rich enhancements in the future
• Extremely simple Skin Management UI that non-technical users assigned to perform tenant administrative tasks can use to adjust their skin look
• Approach that can be used in non-tenant situations to allow for simple, basic adjustments to a general uPortal skin experience
• Leverage if possible the same skin technologies used for Respondr
• Do not require duplication of Respondr skin files to allow for configurable skinning to ease long term maintenance.

The Skin Manager is NOT intended to significantly alter the skins as would be done for a typical University deployment where the University's staff would typically copy Respondr's default skin and modify the source files to achieve the desired skin appearance.