Java and XPages
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.
MVC Diagram
Components we will run into and their role in
MVC
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 :::
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
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
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
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
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
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
Everything in a diagram
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

Java and XPages

  • 1.
  • 2.
    MVC Software architectural pattern. Dividesan 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.
  • 4.
    Components we willrun into and their role in MVC
  • 5.
    FacesServlet ● Part ofController 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 ● Partof 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 ● Partof 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.
  • 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