Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Background

There is a client that wants to support large numbers of tenants (800+) 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) using the uPortal's Administrative UIs.

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 page-top or 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 if a site has multiple tenants).  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
  • Skin configuration changes must apply immediately and not require a server restart
  • Skin configuration changes apply immediately to all servers in a cluster without administrative intervention
  • Approach that can be used in non-tenant situations to allow for simple, basic adjustments to a general uPortal skin experience, hopefully growing more sophisticated over time
  • 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 generally copy Respondr's default skin and modify the source files to achieve the desired skin appearance.

 

  • No labels