Oracle® Application Development Framework Developer's Guide For Forms/4GL Developers 10g Release 3 (10.1.3.0) Part Number B25947-02 |
|
|
View PDF |
This appendix highlights the most commonly used methods in the interfaces and classes of the ADF Business Components layer of Oracle ADF.
This appendix contains the following sections:
All of the interfaces described in this section are designed for use by client-layer code and are part of the oracle.jbo.*
package.
Note:
The corresponding implementation classes for theseoracle.jbo.*
interfaces are consciously designed to not be directly accessed by client code. As you'll see in the Section D.2, "Most Commonly Used Methods In the Business Service Tier" section below, the implementation classes live in the oracle.jbo.server.*
package and generally have the suffix Impl
in their name to help remind you not to using them in your client-layer code.The ApplicationModule is a business service component that acts as a transactional container for other ADF components and coordinates with them to implement a number of J2EE design patterns important to business application developers. These design pattern implementations enable your client code to work easily with updatable collections of value objects, based on fast-lane reader SQL queries that retrieve only the data needed by the client, in the way the client wants to view it. Changes made to these value objects are automatically coordinated with your persistent business domain objects in the business service tier to enforce business rules consistently and save changes back to the database.
Table D-1 ApplicationModule Interface
If you want to... | Call this ApplicationModule interface method... |
---|---|
Access an existing view object instance by name |
|
Creating a new view object instance from an existing definition |
|
Creating a new view object instance from a SQL Statement |
Note: This incurs runtime overhead to describe the "shape" of the dynamic query's |
Access a nested application module instance by name |
|
Create a new nested application module instance from an existing definition |
|
Find a view object instance in a nested application module |
Note: To find an instance of a view object belonging to a nested application module you use a dot notation |
Accessing the current transaction object |
|
In addition to generic ApplicationModule
access, Oracle JDeveloper 10g can generate you a custom YourApplicationModuleName
interface containing service-level custom methods that you've chosen to expose to the client. You do this by visiting the Client Interface tab of the Application Module editor, and shuttling the methods you'd like to appear in your client interface into the Selected list. JDeveloper will also generate an appropriate YourApplicationModuleName
Client
client proxy implementation class that is used automatically by your remote client in the case that you deploy your application module as an EJB Session Bean or whenever you use your application module in Batch Mode.
The Transaction interface exposes methods allowing the client to manage pending changes in the current transaction.
Table D-2 Transaction Interface
If you want to... | Call this Transaction interface method... |
---|---|
Commit pending changes |
|
Rollback pending changes |
|
Execute a one-time database command or block of PL/SQL |
Note: Commands that require retrieving |
Validate all pending invalid changes in the transaction |
|
Change the default locking mode |
Note: You can set the locking mode in your configuration by setting the property |
Decide whether to use bundled exception reporting mode or not. |
Note: ADF controller layer support sets this parameter to |
Decide whether entity caches will be cleared upon a successful commit of the transaction. |
Note: Default is |
Decide whether entity caches will be cleared upon a rollback of the transaction. |
Note: Default is |
Clear the entity cache for a specific entity object. |
|
A ViewObject encapsulates a database query and simplifies working with the RowSet
of results it produces. You use view objects to project, filter, join, or sort business data using SQL from one or more tables into exactly the format that the user should see it on the page or panel. You can create "master/detail" hierarchies of any level of depth or complexity by connecting view objects together using view links. View objects can produce read-only query results, or by associating them with one ore more entity objects at design time, can be fully updatable. Updatable view objects can support insertion, modification, and deletion of rows in the result collection, with automatic delegation to the correct business domain objects.
Every ViewObject
aggregates a "default rowset" for simplifying the 90% of use cases where you work with a single RowSet
of results for the ViewObject
's query. A ViewObject
implements all the methods on the RowSet
interface by delegating them to this default RowSet
. That means you can invoke any RowSet
methods on any ViewObject
as well.
Every ViewObject
implements the StructureDef
interface to provide information about the number and types of attributes in a row of its row sets. So you can call StructureDef
methods right on any view object.
Table D-3 ViewObject Interface
If you want to... | Call this ViewObject interface method... |
---|---|
Set an additional runtime WHERE clause on the rowset |
Note: This |
Set a dynamic ORDER BY clause |
|
Create a Query-by-Example criteria collection |
Note: You then create one or more |
Apply a Query-by-Example criteria collection |
|
Set a query optimizer hint |
|
Access the attribute definitions for the key attributes in the view object |
|
Add a dynamic attribute to rows in this view object's row sets |
|
Clear all row sets produced by a view object |
|
Remove view object instance an its resources |
|
Set an upper limit on the number of rows that the view object will attempt to fetch from the database. |
Note: Default is -1 which means to impose no limit on how many rows would be retrieved from the database if you iterate through them all. By default they are fetched lazily as you iterate through them. |
In addition to generic ViewObject
access, JDeveloper 10g can generate you a custom YourViewObjectName
interface containing view-object level custom methods that you've chosen to expose to the client. You do this by visiting the Client Interface tab of the View Object editor, and shuttling the methods you'd like to appear in your client interface into the Selected list. JDeveloper will also generate an appropriate YourViewObjectName
Client
client proxy implementation class that is used automatically by your remote client in the case that you deploy your application module as an EJB Session Bean or whenever you use your application module in Batch Mode.
A RowSet is a set of rows, typically produced by executing a ViewObject
's query.
Every RowSet
aggregates a "default rowset iterator" for simplifying the 90% of use cases where you only need a single iterator over the rowset. A RowSet
implements all the methods on the RowSetIterator
interface by delegating them to this default RowSetIterator
. This means you can invoke any RowSetIterator
method on any RowSet
(or ViewObject
, since it implements RowSet as well for its default RowSet).
Table D-4 RowSet Interface
If you want to... | Call this RowSet interface method... |
---|---|
Set a where clause bind variable value |
Note: Bind variable ordinal positions are zero-based |
Avoid view object row caching if data is being read only once |
|
Force a row set's query to be (re)executed |
|
Estimate the number of rows in a view object's query result |
|
Produce XML document for rows in View Object rowset |
|
Process all rows from an incoming XML document |
|
Set whether rowset will automatically see new rows based on the same entity object created through other rowsets |
|
Create secondary iterator to use for programmatic iteration |
Note: If you plan to find and use the secondary iterator by name later, then pass in a string name as the argument, otherwise pass |
A RowSetIterator is an iterator over the rows in a RowSet
. By default it allows you to iterate both forward and backward through the rows.
Table D-5 RowSetIterator Interface
If you want to... | Call this RowSetIterator interface method... |
---|---|
Get the first row of the iterator's rowset |
|
Test whether there are more rows to iterate |
|
Get the next row of iterator's rowset |
|
Find row in this iterator's rowset with a given Key value |
Note: It's important that the |
Create a new row to populate for insertion |
Note: The new row will already have default values set for attributes which either have a static default value supplied at the entity object or view object level, or if the values have been populated in an overridden |
Create a view row with an initial set of foreign key and/or discriminator attribute values |
Note: You use this method when working with view objects that can return one of a "family" of entity object subtypes. By passing in the correct discriminator attribute value in the call to create the row, the framework can create you the correct matching entity object subtype underneath. |
Insert a new row into the iterator's rowset |
Note: It's a good habit to always immediately insert a newly created row into the rowset. That way you will avoid a common gotcha of creating the row but forgetting to insert it into the rowset. |
Get the last row of the iterator's rowset |
|
Get the previous row of the iterator's rowset |
|
Reset the current row pointer to the slot before the first row |
|
Close an iterator when done iterating |
|
Set a given row to be the current row |
|
Remove the current row |
|
Remove the current row to later insert it at a different location in the same iterator. |
|
Remove the current row from the current collection but do not remove it from the transaction. |
|
Set/change the number of rows in the range (a "page" of rows the user can see) |
|
Scroll to view the Nth page of rows (1-based) |
|
Scroll to view the range of rows starting with row number N |
|
Set row number N in the range to be the current row |
|
Get all rows in the range as a Row array |
|
A Row is generic value object. It contains attributes appropriate in name and Java type for the ViewObject
that it's related to.
Table D-6 Row Interface
If you want to... | Call this Row interface method... |
---|---|
Get the value of an attribute by name |
|
Set the value of an attribute by name |
|
Produce an XML document for a single row |
|
Eagerly validate a row |
|
Read row attribute values from XML |
|
Remove the row |
|
Flag a newly created row as temporary (until updated again) |
|
Retrieve the attribute structure definition information for a row |
|
Get the Key object for a row |
|
In addition to generic Row
access, JDeveloper 10g can generate you a custom YourViewObjectName
Row
interface containing your type-safe attribute getter and setter methods, as well as any desired row-level custom methods that you've chosen to expose to the client. You do this by visiting the Client Row Interface tab of the View Object editor, and shuttling the methods you'd like to appear in your client interface into the Selected list. JDeveloper will also generate an appropriate YourViewObjectName
RowClient
client proxy implementation class that is used automatically by your remote client in the case that you deploy your application module as an EJB Session Bean or whenever you use your application module in Batch Mode.
A StructureDef is an interface that provides access to runtime metadata about the structure of a Row
.
In addition, for convenience every ViewObject
implements the StructureDef
interface as well, providing access to metadata about the attributes in the resulting view rows that its query will produce.
Table D-7 StructureDef Interface
If you want to... | Call this StructureDef interface method... |
---|---|
Access attribute definitions for all attributes in the view object row |
|
Find an attribute definition by name |
|
Get attribute definition by index |
|
Get number of attributes in a row |
|
An AttributeDef provides attribute definition information for any attribute of a View Object row or Entity Object instance like attribute name, Java type, and SQL type. It also provides access to custom attribute-specific metadata properties that can be inspected by generic code you write, as well as UI hints that can assist in rendering an appropriate user interface display for the attribute and its value.
Table D-8 AttributeDef Interface
If you want to... | Call this AttributeDef interface method... |
---|---|
Get the Java type of the attribute |
|
Get the SQL type of the attribute |
Note: The |
Determine the kind of attribute |
Note: If it's a simple attribute, it returns one of the constants |
Get the Java type of elements contained in an |
|
Get the SQL type of elements contained in an |
|
Get the name of the attribute |
|
Get the index position of the attribute |
|
Get the precision of a numeric attribute or the maximum length of a String attribute |
|
Get the scale of a numeric attribute |
|
Get the underlying column name corresponding to the attribute |
|
Get attribute-specific custom property values |
|
Get the UI |
|
Test whether the attribute is mandatory |
|
Test whether the attribute is queriable |
|
Test whether the attribute is part of the primary key for the row |
|
The AttributeHints interface related to an attribute exposes UI hint information that attribute that you can use to render an appropriate user interface display for the attribute and its value.
Table D-9 AttributeHints Interface
If you want to... | Call this AttributeHints interface method... |
---|---|
Get the UI label for the attribute |
|
Get the tool tip for the attribute |
|
Get the formatted value of the attribute, using any format mask supplied |
|
Get the display hint for the attribute |
Note: Will have a String value of either |
Get the preferred control type for the attribute |
|
Parse a formatted string value using any format mask supplied for the attribute |
|
The implementation classes corresponding to the oracle.jbo.*
interfaces described above are consciously designed to not be directly accessed by client code. They live in a different package named oracle.jbo.server.*
and have the Impl
suffix in their name to help remind you not to using them in your client-layer code.
In your business service tier implementation code, you can use any of the same methods that are available to clients above, but in addition you can also:
Safely cast any oracle.jbo.*
interface to its oracle.jbo.server.*
package implementation class and use any methods on that Impl
class as well.
Override any of the base framework implementation class' public
or protected
methods to augment or change its default functionality by writing custom code in your component subclass before or after calling super.
methodName
()
.
This section provides a summary of the most frequently called, written, and overridden methods for the key ADF Business Components classes.
Before examining the specifics of individual classes, it's important to understand how you can control which custom Java files each of your components will use. When you don't need a customized subclass for a given component, you can just let the base framework class handle the implementation at runtime.
Each business component you create comprises a single XML component descriptor, and zero or more related custom Java implementation files. Each component that supports Java customization has a Java tab in its component editor in the JDeveloper 10g IDE. By checking or unchecking the different Java classes, you control which ones get created for your component. If none of the boxes is checked, then your component will be an XML-only component, which simply uses the base framework class as its Java implementation. Otherwise, tick the checkbox of the related Java classes for the current component that you need to customize. JDeveloper 10g will create you a custom subclass of the framework base class in which you can add your code.
Note:
You can setup global IDE preferences for which Java classes should be generated by default for each ADF business component type by selecting Tools | Preferences... | Business Components and ticking the checkboxes to indicate what you want your defaults to be.A best practice is to always generate Entity Object and View Row classes, even if you don't require any custom code in them other than the automatically-generated getter and setter methods. These getter and setter methods offer you compile-time type checking that avoids discovering errors at runtime when you accidentally set an attribute to an incorrect kind of value.
The ApplicationModuleImpl class is the base class for application module components. Since the application module is the ADF component used to implement a business service, think of the application module class as the place where you can write your service-level application logic. The application module coordinates with view object instances to support updatable collections of value objects that are automatically "wired" to business domain objects. The business domain objects are implemented as ADF entity objects.
{para}?>
Table D-10 Methods You Typically Call on ApplicationModuleImpl
If you want to... | Call this method of the ApplicationModuleImpl class |
---|---|
Perform any of the common application module operations from inside your class, which can also be done from the client |
See the Section D.1.1, "ApplicationModule Interface" section above. |
Access a view object instance that you added to the application module's data model at design time |
Note: JDeveloper 10g generates this type-safe view object instance getter method for you to reflect each view object instance in the application module's design-time data-model. |
Access the current DBTransaction object |
|
Access a nested application module instance that you added to the application module at design time |
Note: JDeveloper 10g generates this type-safe application module instance getter method for you to reflect each nested application module instance added to the current application module at design time. |
{para}?>
Table D-11 Methods You Typically Write in Your Custom ApplicationModuleImpl Subclass
If you want to... | Write a method like this in your custom ApplicationModuleImpl class |
---|---|
Invoke a database stored procedure |
Note: Use appropriate method on the See this sample project for a robust code example of encapsulating a call to a PL/SQL stored procedure inside your application module. |
Expose custom business service methods on your application module |
Note: Select the method name on the Client Interface panel of the application module editor to expose it for client access if required. |
JDeveloper 10g can generate you a custom YourApplicationModuleName
interface containing service-level custom methods that you've chosen to expose to the client. You do this by visiting the Client Interface tab of the Application Module editor, and shuttling the methods you'd like to appear in your client interface into the Selected list.
{para}?>
Table D-12 Methods You Typically Override in Your Custom ApplicationModuleImpl Subclass
If you want to... | Override this method of the ApplicationModuleImpl class |
---|---|
Perform custom setup code the first time an application module is created and each subsequent time it gets used by a different client session. |
Note: This is the method you'd use to setup per-client context info for the current user in order to use database Oracle's Virtual Private Database (VPD) features. It can also be used to set other kinds of PL/SQL package global variables, whose values might be client-specific, on which other stored procedures might rely. This method is also useful to perform setup code that is specific to a given view object instance in the application module. If instead of being instance-specific you want the view object setup code to be initialized for every instance ever created of that view object component, then put the setup logic in an overridden |
Perform custom setup code after the application module's transaction is associated with a database connection from the connection pool. |
Note: Can be a useful place to write a line of code that uses |
Perform custom setup code before the application module's transaction releases its database connection back to the database connection pool. |
Note: If you have set |
Write custom application module state to the state management XML snapshot |
|
Read and restore custom application module state from the state management XML snapshot |
|
The DBTransactionImpl2 class — which extends the base DBTransactionImpl class, and is constructed by the DatabaseTransactionFactory class — is the base class that implements the DBTransaction interface, representing the unit of pending work in the current transaction.
{para}?>
Table D-13 Methods You Typically Call on DBTransaction
If you want to... | Call this method on the DBTransaction object |
---|---|
Commit the transaction |
|
Rollback the transaction |
|
Eagerly validate any pending invalid changes in the transaction |
|
Create a JDBC |
|
Create a JDBC |
|
Create a JDBC |
|
Add a warning to the transaction's warning list. |
|
{para}?>
Table D-14 Methods You Typically Override in Your Custom DBTransactionImpl2 Subclass
If you want to... | Override this method in your custom DBTransactionImpl2 class |
---|---|
Perform custom code before or after the transaction commit operation |
|
Perform custom code before or after the transaction rollback operation |
|
In order to have your custom DBTransactionImpl2
subclass get used at runtime, there are two steps you must follow:
Create a custom subclass of DatabaseTransactionFactory
that overrides the create method to return an instance of your custom DBTransactionImpl2
subclass like this:
package com.yourcompany.adfextensions; import oracle.jbo.server.DBTransactionImpl2; import oracle.jbo.server.DatabaseTransactionFactory; import com.yourcompany.adfextensions.CustomDBTransactionImpl; public class CustomDatabaseTransactionFactory extends DatabaseTransactionFactory { /** * Return an instance of our custom CustomDBTransactionImpl class * instead of the default implementation. * * @return An instance of our custom DBTransactionImpl2 implementation. */ public DBTransactionImpl2 create() { return new CustomDBTransactionImpl(); } }
Tell the framework to use your custom transaction factory class by setting the value of the TransactionFactory
configuration property to the fully-qualified class name of your custom transaction factory. As with other configuration properties, if not supplied in the configuration XML file, it can be provided alternatively as a Java system parameter of the same name.
The EntityImpl class is the base class for entity objects, which encapsulate the data, validation rules, and business behavior for your business domain objects.
{para}?>
Table D-15 Methods You Typically Call on EntityImpl
If you want to... | Call this method in your EntityImpl subclass |
---|---|
Get the value of an attribute |
Note: Code-generated getter method calls |
Set the value of an attribute |
Note: Code-generated setter method calls |
Get the value of an attribute by name |
|
Set the value of an attribute by name |
|
Eagerly perform entity object validation |
|
Refresh the entity from the database |
|
Populate the value of an attribute without marking it as being changed, but sending notification of its being changed so UI's refresh the value on the screen/page. |
|
Access the definition object for an entity |
|
Get the Key object for an entity |
|
Determine the state of the entity instance, irrespective of whether it has already been posted in the current transaction (but not yet committed) |
Note: Will return one of the constants |
Determine the state of the entity instance |
Note: This method is typically only relevant if you are programmatically using the |
Get the value originally read from the database for a given attribute |
|
Eagerly lock the database row for an entity instance |
|
{para}?>
Table D-16 Methods You Typically Write in Your Custom EntityImpl Subclass
If you want to... | Write a method like this in your EntityImpl subclass |
---|---|
Perform attribute-specific validation |
Note: Register the attribute validator method by adding a "MethodValidator" on correct attribute in the Validation panel of the Entity Object editor. When you register the method validation |
Perform entity-level validation |
Note: Register the entity-level validator method by adding a "MethodValidator" on the entity in the Validation panel of the Entity Object editor. |
Calculate the value of a transient attribute |
Add your calculation code to the generated |
{para}?>
Table D-17 Methods You Typically Override on EntityImpl
If you want to... | Override this method in your custom EntityImpl subclass... |
---|---|
Set calculated default attribute values, including programmatically populating thbe primary key attribute value of a new entity instance. |
Note: After calling |
Modify attribute values before changes are posted to the database |
|
Augment/change the standard INSERT, UPDATE, or DELETE DML operation that the framework will perform on your entity object's behalf to the database |
Note: Check the value of the operation flag to the constants |
Perform complex, SQL-based validation after all entity instances have been posted to the database but before those changes are committed. |
|
Insure that a related, newly-created, parent entity gets posted to the database before the current child entity on which it depends |
Note: If the parent entity is related to this child entity via a composition association, then the framework already handles this automatically. If they are only associated (but not composed) then you need to override |
Note:
It is possible to write attribute-level validation code directly inside the appropriateset
AttributeName
method of your EntityImpl
class, however adopting the MethodValidator
approach suggested above results in having a single place on the Validation tab of the Entity Object editor to look in order to understand all of the validations in effect for your entity object, so it can result in easier to understand components.WARNING:
It is also possible to override the validateEntity()
method to write entity-level validation code, however if you want to maintain the benefits of the ADF bundled exception mode — where the framework collects and reports a maximal set of validation errors back to the client user interface — it is recommended to adopt the MethodValidator
approach suggested in the table above. This allows the framework to automatically collect all of your exceptions that your validation methods throw without your having to understand the bundled exception implementation mechanism. Overriding the validateEntity()
method directly shifts the responsibility on your own code to correctly catch and bundle the exceptions like Oracle ADF would have done by default, which is non-trivial and a chore to remember and hand-code each time.
The EntityDefImpl class is a singleton, shared metadata object for all entity objects of a given type in a single Java VM. It defines the structure of the entity instances and provides methods to create new entity instances and find existing instances by their primary key.
{para}?>
Table D-18 Methods You Typically Call on EntityDefImpl
If you want to... | Call the EntityDefImpl method |
---|---|
Find an entity object of a this type by its primary key |
Note: See this tip for getting |
Access the current |
|
Find any |
|
Retrieve the value of an entity object's custom property |
|
Set the value of an entity object's custom property |
|
Create a new instance of an entity object |
Note: Alternatively, you can expose custom |
Iterate over the entity instances in the cache of this entity type. |
|
Access |
|
{para}?>
Table D-19 Methods You Typically Write on EntityDefImpl
If you want to... | Write a method like this in your custom EntityDefImpl class |
---|---|
Allow other classes to create an entity instance with an initial type-safe set of attribute values or setup information. |
Note: Internally, this would create and populate an instance of a |
{para}?>
Table D-20 Methods You Typically Override on EntityDefImpl
If you want to... | Call the EntityDefImpl method |
---|---|
Perform custom metadata initialization when this singleton metaobject is loaded. |
|
Avoid using the |
Note: Return false to disable the use of |
Control whether the UPDATE statements issued for this entity update only changed columns, or all columns |
Note: Defaults to |
Find any EntityDefImpl object by its fully-qualified name |
Note: Static method. |
Set the value of an entity object's custom property |
|
Allow other classes to create a new instance an entity object without doing so implicitly via a view object. |
Note: If you don't write a custom create method as noted in the previous section, you'll need to override this method and widen the visibility from |
The ViewObjectImpl class the base class for view objects.
{para}?>
Table D-21 Methods You Typically Call on ViewObjectImpl
If you want to... | Call this ViewObjectImpl method |
---|---|
Perform any of the common view object, rowset, or rowset iterator operations from inside your class, which can also be done from the client |
See the Section D.1.3, "ViewObject Interface", Section D.1.4, "RowSet Interface", and Section D.1.5, "RowSetIterator Interface" sections above. |
Set an additional runtime WHERE clause on the default rowset |
|
Defines a named bind parameter. |
|
Removes a named bind parameter. |
|
Set bind variable values on the default rowset by name. Only works when you have formally defined named bind variables on your view object. |
|
Set bind variable values on the default rowset. Use this method for view objects with binding style of "Oracle Positional" or "JDBC Positional" when you have not formally defined named bind variables. |
|
Retrieved a subset of rows in a view object's row set based on evaluating an in-memory filter expression. |
|
Retrieved a subset of rows in the current range of a view object's row set based on evaluating an in-memory filter expression. |
|
Set the number of rows that will be fetched from the database per round-trip for this view object. |
Note: The default fetch size is a single row at a time. This is definitely not optimal if your view object intends to retrieve many rows, so you should either set the fetch size higher at design time on the Tuning tab of the View Object editor, or set it at runtime using this API. |
{para}?>
Table D-22 Methods You Typically Write in Your Custom ViewObjectImpl Subclass
If you want to... | Write a method like this in your ViewObjectImpl subclass |
---|---|
Provide clients with type-safe methods to set bind variable values without exposing positional details of the bind variables themselves |
Note: Internally, this method would call the setWhereClauseParam() API to set the correct bind variables with the values provided in the type-safe method arguments. |
JDeveloper 10g can generate you a custom YourViewObjectName
interface containing view object custom methods that you've chosen to expose to the client. You can accomplish this by visiting the Client Interface tab of the View Object editor, and shuttling the methods you'd like to appear in your client interface into the Selected list.
{para}?>
Table D-23 Methods You Typically Override in Your Custom ViewObjectImpl Subclass
If you want to... | Override this ViewObjectImpl method |
---|---|
Initialize custom view object class members (not row attributes!) when the view object instance is created for the first time. |
Note: This method is useful to perform setup logic that is applicable to every instance of a view object that will ever get created, in the context of any application module. If instead of generic view object setup logic, you need to perform logic specific to a given view object instance in an application module, then override the |
Write custom view object instance state to the state management XML snapshot |
|
Read and restore custom view object instance state from the state management XML snapshot |
|
Customize the behavior of view object query execution, independent of whether the query was executed explicitly by calling |
|
Change/augment the way that the |
|
The ViewRowImpl class the base class for view row objects.
Table D-24 Methods You Typically Call on ViewRowImpl
If you want to... | Write a method like this in your custom ViewRowImpl class |
---|---|
Perform any of the common view row operations from inside your class, which can also be done from the client |
See the Section D.1.6, "Row Interface" section above. |
Get the value of an attribute |
|
Set the value of an attribute |
|
Access the underlying entity instance to which this view row is delegating attribute storage. |
Note: You can change the name of the entity usage alias name on the Entity Objects tab of the View Object Editor |
{para}?>
Table D-25 Methods You Typically Write on ViewRowImpl
If you want to... | Write a method like this in your custom ViewRowImpl class |
---|---|
Calculate the value of a view object level transient attribute |
Note: JDeveloper generates the skeleton of the method for you, but you need to write the custom calculation logic inside the method body. |
Perform custom processing of the setting of a view row attribute |
Note: JDeveloper generates the skeleton of the method for you, but you need to write the custom logic inside the method body if required. |
Determine the updateability of an attribute in a conditional way. |
|
Custom methods that expose logical operations on the current row, optionally callable by clients |
Note: Often these view-row level custom methods simply turn around and delegate to a method call on the underlying entity object related to the current row. |
JDeveloper 10g can generate you a custom YourViewObjectName
Row
interface containing view row custom methods that you've chosen to expose to the client. You can accomplish this by visiting the Client Row Interface tab of the View Object editor, and shuttling the methods you'd like to appear in your client interface into the Selected list.
{para}?>
Before you begin to develop application specific business components, Oracle recommends creating yourself a layer of classes that extend all of the ADF Business Components framework base implementation classes described in this paper. An example of a customized framework base class for application module components might look like this:
package com.yourcompany.adfextensions; import oracle.jbo.server.ApplicationModuleImpl; public class CustomApplicationModuleImpl extends ApplicationModuleImpl { /* * We might not yet have any custom code to put here yet, but * the first time we need to add a generic feature that all of * our company's application modules need, we will be very happy * that we thought ahead to leave ourselves a convenient place * in our class hierarchy to add it so that all of the application * modules we have created will instantly benefit by that new feature, * behavior change, or even perhaps, bug workaround. */ }
A common set of customized framework base classes in a package name of your own choosing like com.yourcompany.adfextensions
, each importing the oracle.jbo.server.*
package, would consist of the following classes.
public class CustomEntityImpl extends EntityImpl
public class CustomEntityDefImpl extends EntityDefImpl
public class CustomViewObjectImpl extends ViewObjectImpl
public class CustomViewRowImpl extends ViewRowImpl
public class CustomApplicationModuleImpl extends ApplicationModuleImpl
public class CustomDBTransactionImpl extends DBTransactionImpl2
public class CustomDatabaseTransactionFactory extends DatabaseTransactionFactory
For completeness, you may also want to create customized framework classes for the following classes as well, but overriding anything in these classes would be a fairly rare requirement.
public class CustomViewDefImpl extends ViewDefImpl
public class CustomEntityCache extends EntityCache
public class CustomApplicationModuleDefImpl extends ApplicationModuleDefImpl