Versions Compared

Old Version 5

changes.mady.by.user James Wennmacher

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Petro

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: noted idea of doing skin compile work asynchronously with rendering, by performing as task on a non-render thread.

...

  • 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.
  • Be able to handle a large number of tenants, upwards of 800+, with reasonable system resource impacts.

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.

...

  • Expand the number of skin variables and possibly include images or other elements to allow the skin to be more heavily configured.
  • Allow the administrator to 'preview' the skin changes in a way that only the administrator sees the affects of the changes until the skin changes are persisted.
  • Enhance the security infrastructure to limit the users who can configure a skin so a delegated administrator can affect only their skin and not other tenant's skins.
  • Expand to a database-driven strategy where the skin is stored in the database and not necessarily on the file system.

Opportunities for consideration

  • Move skin compilation into an asynchronous task on a non-render thread, getting the details right so that uPortal rendering does not block on in-process skin (re-)compilation and users do not get half-baked in-process skin artifacts during skin (re-)compilation.