 |
Tuesday, October 19, 2004 |
Using the ADF Business Components, our prescriptive architecture's best practice is to implement all validation in your entity objects. This way business validation rules are applied consistently regardless of application module or view object those entities might be involved with.
Assuming you have an entity object named FiscalYear, with attributes BeginDate and EndDate of type oracle.jbo.domain.Date, here are the steps for implementing a code-based validation rule that checks that the EndDate is greater than the BeginDate
- Write a validation method in your FiscalYearImpl.java class like this. It's name must begin with the prefix validate:
/**
* Return false if BeginDate and EndDate
* are not null and BeginDate > EndDate
*
* The error message is supplied when attaching
* a MethodValidator for this method on the
* validation panel of the entity object editor.
*/
public boolean validateDateRange() {
return getEndDate() == null
||getHiredate() == null
||getHiredate().compareTo(getEndDate()) <= 0;
}
- Edit FiscalYear entity with the Entity Editor, and visit the Validation panel
- Click on the FiscalYear entity name in the tree, and press (New...) to add a new entity-level rule
- Select the type of MethodValidator and pick validateDateRange() from the list of methods
- Enter a validation failure message in the error message box.
- Click (OK) to add the new entity-level method validation rule, and (OK) again to finish.
That's it.
11:12:32 PM 
|
|
The simple example apps keep popping out of my daily work in helping customers understand and best use the ADF framework. I've added a few new examples over on my Not Yet Documented Examples page today:
- Deleting Multiple Employees Based on Selected Checkboxes
- Deleting an Employee with Confirmation in a Web Application
- Posting Multi-Level XML Data Over HTTP to ADF Business Components
- Using a Transient Boolean Flag on a View Object to Mark and Filter Selected Rows
Once I get some free time, I'll begin properly explaining each one and converting them into OTN HowTo papers, but in the interim, these might be useful to some developers eager to take a peek.
3:08:16 PM
|
|
The ADF design time only sees components in packages that are:
- Included in the current project for editing, or
- Imported read-only in the current project from a library.
The implication of adding a package of business components to your JDeveloper project (by adding the packagename.xml file for the package of components named packagename) is that you can edit any aspect if needed using the BC4J wizards, and you see the source code.
The implication of importing a package of business components from a library is that the components are available in the various ADF BC design time wizards to be referred to by editable components in your current project, but you cannot modify the imported components. In fact, the Java source code need not be present in the library JAR file at all (just *.class and *.xml files).
You create a JAR file of ADF BC components using our simple JAR file BC Deployment profile option. You can access that from the right-mouse menu of an application module component by selecting "Business Components Deployment...".
You import a package of ADF BC components by:
- Creating a library for your JAR file on the Libraries tab of your project properties
- Including that library in your project's library list
- File | Import... | Business Components
- Use the file open dialog to navigate into your library's JAR file and select the packagename.xml file for the package named "packagename" of components from that library that you want to import.
You'll see if you select one of the imported components that you can inspect its properties in the Business Components editors, but everything is greyed out since imported components are not editable in the importing project by design.
2:59:24 PM
|
|
© Copyright 2008 Steve Muench.
|
|
