presentation on Java, JSF and XPages for IBM Lotus Notes/Domino and XPages developers

1. Java and XPages

2. MVC
Software architectural pattern.
Divides an application into three interconnected parts.
Separates internal representations of information from the ways information is presented
to the user.
Model:
These are your Java objects that contain and manipulate the data from the database and
implement business rules for managing that data.
View:
These are your presentation Java objects. Mostly a 1-to-1 relationship between an XPage
(graphical view) and a related view Bean.
Controller:
This middle layer is the JSF API. No code is written here by the developer of JSF applications
(including XPages). This is the FacesServlet.

3. MVC Diagram

4. Components we will run into and their role in
MVC

5. FacesServlet
● Part of Controller in MVC
● Core of the JSF architecture, part of the web application server (Domino) API
– E.g. renders the XPage
– E.g. receives requests from a XPage
– E.g. creates & updates Managed Beans
● Already setup for us by IBM. We do not write code for FacesServlet :::

6. XPages
● Sounds familiar :::
● Part of View in MVC
– E.g. controls the look and feel of your web page
– E.g acts as the set of instructions for the FacesServlet to do its job.
● All of those tags/controls you place on the XPage have related Java code behind the
scenes.
– Simple as HTML rendering information
– Or complex processing instructions for datasets
– All executed by the FacesServlet

7. Managed Bean
● Part of View in MVC
● Simplified: a set of instructions for the FacesServlet to process
● XPages does nothing to or with a Managed Bean
● XPages stores only references to a Managed Bean
– Tells FacesServlet to place data in the HTML
– Tells to store data in the Managed Bean
● Acts as the client to the Façade
Example: EmployeeBean
● Primary goal to work only at the View layer
● Should not contain data processing business logic
– Delegate this to the Model layer

8. CRUD Facade
● Part of Model in MVC
● Enclose the business logic of retrieving data from the system
– Create Read Update Delete actions
● Provides a client interface to a logically grouped set of instructions executed on other
Java objects.
– Managed Bean is the client 
– Low level work and instructions are delegated to classes that make up the Data
Access Objects
● Example: EmployeeCRUDFacade

9. Data Access Object (DAO) – Interface
● Part of Model in MVC
● Sort of contract:
– Common methods that each DAO must implement
– From ”application point of view”, not from the system or database.
– The client (Facade) can always expect to run the same method, regardless
underlying database (Domino, Oracle, SQL)
● Example: EmployeeDOA

10. Data Access Object (DAO) - Database
● Describes how to access the data from ”database point of view”
● Domino:
– Database (NSF)
– Views
– Collections
– Notes document
– Fields etcetera
● Example: DominoEmployeeDOA

11. Data object class
● Part of Model in MVC
● Low(est) level description of data/object e.g. an employee
● Contains properties (~ fields) and methods (getter and setters for fields)
● Contains no real logic

12. Everything in a diagram

13. Java classes & conventions
● Objects represented by classes
● Resides in a package (~ folder):
– Toplevel domain.domain.application/project.folder.object
– E.g. se.acme.project.model.employee.class
●
● *1 Class names starts with capital e.g. Employee.class
● *2 Package resides in WebContent/WEB-INF/src folder
Documentation:
*1) http://www.oracle.com/technetwork/java/codeconventions-135099.html
*2) https://www-10.lotus.com/ldd/ddwiki.nsf/dx/Creating_a_Java_Control_in_an_NSF