Overview
Most of the user interface involves Spring MVC “views”, which are rendered with a templating engine theoretically chosen from a number of supported options. While this is extensible, the three view resolvers installed by default, in order, are:
org.springframework.web.servlet.view.BeanNameViewResolver – used rarely, it resolves a view against a bean of the same name in the Spring context
net.shibboleth.ext.spring.velocity.VelocityViewResolver – the most commonly used, supports the Velocity template engine used in other places in the IdP
org.springframework.web.servlet.view.InternalResourceViewResolver – a fallback that relies on JSP templates, mainly used for the IdP’s status page
Virtually of the views supplied with the software are Velocity templates (with a “vm” extension). A handful are installed by default because they are core functionality and not installed by a specific Module. The rest are installed as specific modules that manage them are enabled. For example the “login form” consists of a couple of views that are actually part of the Password login flow, which is enabled by default.
When Spring looks for a view template, it will search for one with the “vm” extension in the location(s) specified by the idp.views property, and if it can’t locate one, it will search inside the war within WEB-INF/jsp for a template with the “jsp” extension and run that instead.
For detailed information on the Velocity-related content of the views, see the VelocityVariables topic.
Look and Feel
TBD