Domino Web Site rules have been around since long before XPages. The Domino Administrator guide defines Web Site rules as follows:
Web Site rules are documents that help you maintain the organization of a Web site. They have two main uses:
- Enable the administrator to create a consistent and user-friendly navigation scheme for a Web site, which is independent of the site’s actual physical organization.
- Allow parts of the site to be relocated or reorganized without breaking existing links or browser bookmarks.
The definition from IBM says that there are “two main reasons”. But if you are familiar with Web Site rules you know that they can also be used to provide connectivity to resources on the file system as well as manipulating the response headers. Those are excellent capabilities and were sorely needed. But in this article we are going to focus on the primary definition provided by IBM and how XPages can provide a little extra help where the Web Site rules begin to conflict and fail.
Web Site Rules Brief Overview
Domino offers four different types of Web Site rules:
- Substitution Rules
- Redirection Rules
- Directory Rules
- HTTP Response Header Rules
This article will focus on the first two types of rules. Continue reading
When implementing a JavaServer Faces (JSF) based framework for your XPages, you may decide to use a PhaseListener, or two, or three, or any number you want. PhaseListeners can be very powerful tools to help perform centralized processing for your application. Before we dive into the main topic of this article, it may be helpful to provide a base understanding of PhaseListeners and how to define one. If you already know how to use a PhaseListener then feel free to jump the next section.
What is a PhaseListener and how would I use it?
As JSF processes requests it fires specific events. These events are called Continue reading
In the previous installment of this series we completed our Model layer described in the Model-View-Controller (MVC) architecture. In that article we covered the façade (or service) layer:
- EmployeeCRUDFacade: A service layer class to handle data manipulation and data business rules for access by client code that should not work directly with the model layer.
Examples of data manipulation code and data business rule code include:
- Calculate the age of an employee. Your database holds a birthdate, but not an age.
- Calculate the number of years an employee has worked for your company. Your database holds a hire date but not a length of time.
- Calculate the number of approvals required for a time off request that exceeds a certain number of hours.
Examples of client code that should never access the model directly include:
- Workflow processing code.
- External system integration code.
- UI code (a managed bean…covered in this article).
It may appear on the initial design of an application that this layer is just adding extra code. In other words, why not just let my view bean access the DAO? Continue reading
This article describes how you can create your custom validators by implementing javax.faces.validator.Validator interface. But one problem with this is that you need to create a separate Java class for each validation, for e.g. you would have individual Java classes for validating email, credit card number and so on. And for each Java class you have to add <validator>…</validator> entry in faces-config.xml.