September 28, 2006 by burton.

While the ADF that Oracle provides in JDEV is chock full of cool things, it seems that there are some things that could have been added to it. For example, you have two tables that are related by PK->FK relation that you want to represent in JDEV, the two tables use a trigger for generating the unique ids for the tables. JDEV handles this with a DBSequence, using temp Ids till the record is commited to the table, then it refreshed with the new permanent values.

You create your two entities and an association, linking them together in a parent child relationship. Things are great, the parent records can see the children records, and even the FKs are added into the newly created child records, when you call the create row method. However when you commit your changes, you notice that while the parent table has been updated and the primary key is now the one generated from the trigger, the child records did not update and still have the temp id stored on them, leaving you with orphaned records.

The new ADF guide covers this topic on how you can write the code to fix this, but before the guide was out, and back when JDev was 10.1.2, I wrote method to handle this, that I think is easy to use and works quite well. Lets take a look, the first thing is to go to your enitity objects code (yourEntityImpl.java). If you have not overridden the doDML method, click on the Source->Override from the JDEV Menu. You will get an initial code stub like below:

protected void doDML(int i, TransactionEvent TransactionEvent)
{
super.doDML(i, TransactionEvent);
}

If you are a forms developer and want to put this into perspective, anything you do before the call to the super method is a pre-trigger and anything after is a post-trigger. The first thing I do is relabel the i variable to something more understandable, I like to use operation.

Next we create the flow of the new code, here you can use if thens or the case statement, I prefer case here is the basic code so far:

protected void doDML(int operation, TransactionEvent TransactionEvent)
{
switch (operation)
{
case DML_UPDATE:

{
super.doDML(operation, TransactionEvent);

}break;

case DML_DELETE:
{
super.doDML(operation, TransactionEvent);

}break;

case DML_INSERT:
{
super.doDML(operation, TransactionEvent);

}break;
}
}

Now our Entity object has a handler that can handle all pre and post dml statment actions. The next step is to add in our code to handle the child records on a insert to be able to convert the FK Ids to the permanent one stored on the Parent Record. Here is what the new insert code looks like:

case DML_INSERT:
{
//////////////////////////////////////
// Pre Insert Actions //
/////////////////////////////////////
// Grab the child records before the update to the parent record.

RowIterator UpdateFilesIterator = getWorkFlowSteps_ASC();

//Call the super which saves the records.

super.doDML(operation, TransactionEvent);

//////////////////////////////////////
// Post Insert Actions //
/////////////////////////////////////
//If we did a insert of a work flow, and there are temp sequence numbers that need to be linked
//back to the parent record, this code gets the iterator and loops through the records updating the ids

//Create an instance of the child records.

WorkFlowStepsImpl updateFile;

//Loop throught he list of child records and update with new ID

while (UpdateFilesIterator.hasNext())
{
updateFile = (WorkFlowStepsImpl)UpdateFilesIterator.next();
updateFile.setAttribute(”WorkFlowId”, this.getWorkFlowId().getSequenceNumber());
}
}break;
 

Thats it, the records are saved and all is well. For record deletes you could work the same kind of logic, jsut placing it into the post delete action. I prefer to use the triggers on the database side to handle the cascading deletes.

Any questions or comments on this article please let me know.

Posted in JSF / ADF | Print | 1 Comment »

September 12, 2006 by burton.

Ever wondered how to hide and show components depending on what the user selects on your page. I had a recent requirement for a page that would show the users a list of reports, and depending on which report they selected, to show a list of values that they could select from for the report parameters. My problem is that I had four different tables that I wanted to use, and depending on the report type selected, show the associated table.

Using the PPR features of ADF and the data bindings I was able to get this done. Lets take a look how.

Here is a look at my page in the structure panel, after I dropped all my components onto the page:

The key making this work is the use of the panel group. Once we get done, anything in the panel group will be refreshed when the user selects an item in the reports table.

Ok, we have our page layout, now we need to set the rendered property of each the panel headers in the header group to point to column in the reports table. For this example the reports table has a column title EntityObject, which is the name of the table it uses for a report parameter. The code that goes in the render tag looks like this:

                              rendered=”#{bindings.ReportView1.EntityObject ==’PATCH’}”
                              binding=”#{backing_reports.patchHeader}”
                              id=”patchHeader”>
            

The text in blue is the part that will look at the current row on the reports view and determine if the value is what it is looking for.

Next you need to set up the PPR portion of the page. This for me was confusing, as I always seem to get it backwards to the way I think it should work. The way it works is the the child component’s partial trigger is set to the parents. In this example, the partial trigger on the panel group is set to watch the report table and report table select one objects.

                           id="updateWithPPR"
                           partialTriggers=”table1 tableSelectOne1″>

Again the text in blue is the part that you need to add to your code. Running this page will now only show the item in the panel group that applies to the current selected row in the report view. This idea can be used any way you like, you could have drop downs or other components that work in the same manner.   If you have tips on PPR or some cool demos for this area drop me a note.