The platform mostly uses controllers to render pages on GET requests while leaving everything else to AJAX calls talking directly to facades. There is no need for POST (aside from file upload) when it can be done with AJAX on the background. When controller executes it uses its JPS to render HTML. JSP in turn uses tag libraries to populate its content. Thus all the logic can be embedded into JSP leaving controller as plain as possible. That is what the generic controller is for, it executes common logic (such as checking if the requested page is allowed for this website) and forwarding to JSP. And the JSP takes care of the rest: it may render the data, forward to site-able JSP or use taglib to render Freemarker template.
Controllers configured in Spring XML with optional database configuration. If the controller is also configured in the database, the database configuration takes precedence over XML. This allows to have the default configuration for all pages handled by the controller in XML and reconfigure for certain pages in the database. Almost every XML property can be reconfigured by providing the database alternative value. In order to use this feature the controller must have a page index assigned, it merges XML and database configuration - the platform looks up the configuration in the database by using controller's page index which comes from its XML configuration (or URL mapping in the database). Page index is also used when loading text which is specific to the controller's page template and rendering other page-related resources such as help section, meta headers, etc.
URL mappings configured in the database, such mappings specify a controller which is configured in XML. Then XML merges with database configuration and the result is used while the controller handles the request. Simple as saying: when a user accesses this page on this website then the following controller should be engaged which does the following actions.
If a pack supports multiple websites providing different behaviour per website then this often involves proprietary controller logic. Instead of implementing controllers specific to the pack and wiring beans in Spring XML, mods may be used to alter the behaviour of generic controllers. Mod alters a controller behaviour and can plug through database configuration on per page basis. For example, the captcha mod is plugged into Sign in and Sign up pages thus reusing generic controller in Spring XML instead of defining a new controller bean entry.