Business Components Without the Business: Part II

Last week, I talked about how to code database error messages, entity object classes, and custom exceptions to facilitate integration of database-level validation logic into an ADF application. And I promised that this week, we’d finish off the project by writing the controller-layer code that will turn these custom exceptions into nice, user-friendly error messages, right? Well, I’m not going to do that, because I actually forgot something at the ADF Business Components (ADF BC) layer. Controller stuff next week. I really promise this time.

In the controller layer, we’re going to need to extract a table and column name from attribute bindings. It’s pretty easy to get the column name–we’ll do that next week–but the table name is a bit trickier; in fact, it’s pretty much impossible to do in the controller layer. Instead, we’re going to create a view object service method that accepts a view attribute index and, if that attribute is persistent, returns the name of the table from which it comes. You can actually put this service method, like the overridden doDML() method from last week, into a custom framework class–just remember to add it to a framework interface and expose it on all your particular view objects.

Creating and using a custom framework class is covered well in the ADF Developer’s Guide for Forms/4GL Developers, but creating and using custom framework interfaces are not, so I’ll just say a few words about it here: You can create an interface that extends oracle.jbo.ViewObject and have a particular view object interface extend it by clicking the Interfaces button on the “Client Interface” page of the View Object Editor (which will be enabled after you export any method, including a custom framework method like the one we’ll add here).

At any rate, enough preliminaries. Here’s what your custom framework class should look like:


public class ErrorReportingViewObjectImpl extends ViewObjectImpl {

    public String getUnderlyingTable(int attrIndex) {
        String underlyingTable = null;
        ViewAttributeDefImpl attr = getViewAttributeDefImpls()[attrIndex];
        if (attr.getAttributeKind() == attr.ATTR_PERSISTENT) {
            underlyingTable = attr.getEntityDef().getSource();
        return underlyingTable;

We’re retrieving the view object attribute’s definition based on its index in the view object, and if it’s persistent, retrieving the underlying entity object definition and from that the database table name. We’re just returning null for transient, SQL-derived, or entity-derived attributes; none of those should be involved in a database error anyway. That’s the method you need to expose on a custom interface (let’s call it ErrorReportingViewObject) and export for all of your view objects.

OK, that’s really, truly it for the model.

Leave a Reply

Your email address will not be published. Required fields are marked *