I added sample #24, Passing User-Entered Data in "Non Database Block Fields" to Stored Procedure/Function, to my Not Yet Documented ADF Samples page.
This example presents a very simple JClient panel that allows the user to type into three "dummy fields" and contains two different buttons that are bound to data control methods. Both of these data control methods are implemented in the ExampleModuleImpl class. It required no user coding on the client to implement. The "non database block" view object was created using the view object wizard, selecting the "Rows Populated Programmatically, not Based on a Query" radio group on Step 1 of the wizard (this choice is new in 10.1.2). Then I added the transient attributes, defining their name, type, and marking them to be updateable = always. The form was then created using the ADF/JClient Panel Wizard, then the buttons were added by dropping data control methods as buttons onto the panel. The action bindings created to bind the buttons to the data control methods have their "Requires Update Model" property set to true. One of the data control methods invokes a stored procedure, passing the user-entered values, and the other method invokes a stored function, setting the function return value into another "dummy field". This example illustrates several interesting ideas. One is using a view object with only transient attributes as what Oracle Forms users might think of as a "Non-Database Block". There is a custom framework extension class CustomAppModuleImpl.java that illustrates a simple example of how to write generic framework code (like insuring that a blank row exists in a "non-database block" view object) based on whether or not a custom ViewObject property named InsureEmptyRow is present or not. The NonDBBlock view object in the sample contains such a custom property to cause the generic functionality inherited from CustomAppModuleImpl to kick in. The CustomAppModuleImpl.java also contains some generic helper code to simplify invoking stored procedures and functions that have bind variables.
In general, if you find yourself writing code in the client layer of an ADF-based application that is not strictly-speaking related to the user interface, you should be asking yourself if you couldn't be writing the code in your Application Module impl class over on the "Server" side of the logical three-tier architecture, and invoking it declaratively from the client instead.
9:24:56 PM 
|
|
