Go to XPages Scaffolding

=======================

This project has been rolled into the http://openntf.org/main.nsf/project.xsp?r=project/XPages%20Scaffolding project. That project includes a larger framework in addition to a newer variant of the Controller classes specifically.

——————————————————————————————

XPage Controllers, though a partial misnomer, are the method I have been using to build XPage applications lately and they have allowed me to reorganize my code, leaving a cleaner separation between the UI of the XPage and the business logic. Some time back, I wrote two blog posts describing the general idea and use behind these classes:</p>

https://frostillic.us/controllers1 https://frostillic.us/controllers2

More recently, I recorded a Notes in 9 episode giving an overview of what development using this method looks like:

http://notesin9.com/index.php/2013/04/08/notesin9-106-intro-to-java-controller-classes/

The gist is this: rather than using SSJS on the XPage, all properties and methods are bound to a Java object (the "controller") that contains the code. While this confers some performance benefits from the switch to Java, the primary benefit is organizational: without executable code in the XSP markup, the XPage becomes significantly easier to lay out and maintain. Additionally, the focus on using Java makes it easier to identify areas where code can be shared or restructured for better performance or readability.

To use this code, copy the classes and interfaces in the "frostillicus.controller" package in the included NSF into your application and then add this to your faces-config.xml (see the database's faces-config.xml file for an example):

frostillicus.controller.ControllingViewHandler

Once that code is added, your XPages will have a basic controller object available using the name "pageController". Several events will be automatically tied to the controller (namely, beforeRenderResponse, afterRenderResponse, and afterRestoreView), but, due to the architecture of XPages, beforePageLoad and afterPageLoad must be tied manually, so the starting structure of a controller-backed XPage is:

beforePageLoad=“#{pageController.beforePageLoad}” afterPageLoad=“#{pageController.afterPageLoad}“>

That much will give you an XPage with a properly-connected controller object, but it won't do anything. To create a new controller class for the XPage, create a new Java design element, set its package to "controller", set its class name to be the name of the XPage (e.g. "controller.Forum_Home" for an XPage named "Forum_Home.xsp"), and set it to extend the class "frostillicus.controller.BasicXPageController". Then, you can start adding methods to bind to the front end. For example, this class for a page named "Home" will print a message to the console on page load and also provides a basic "getter" method for use on the front end:

package controller;
import frostillicus.controller.BasicXPageController;
public class Home extends BasicXPageController {
private static final long serialVersionUID = 1L;
@Override
public void beforePageLoad() {

System.out.println("Controller here!");

}
public String getHello() {

return "Hello from controller.Home";

}
}

The actual XPage using this could look like so:

[<!--?xml version="1.0" encoding="UTF-8"?-->]
[<xp:view xmlns:xp="http://www.ibm.com/xsp/core" <br="">    beforePageLoad="#{pageController.beforePageLoad}" afterPageLoad="#{pageController.afterPageLoad}">]
[<xp:text value="#{pageController.hello}">]
[</xp:text></xp:view>]

Included in the package is also a "BasicDocumentController" class that provides a couple document-data-source-specific hooks (postOpenDocument, etc.) and a handful of convenience methods for dealing with document data sources. It assumes that the document in question has its var set to "doc" for ease of use's sake.