When using Oracle JDeveloper 10.1.3.x, you can find it very tempting to create "Create/Edit Record" pages by dropping an ADF Form on a blank JSF page and then adding commit and rollback buttons in the place of the ok and cancel buttons with an action property that returns your users to the browse page.
So let's assume that your faces-config file contains a navigation case labeled "return", that leads from you edit page back to your browse page. In cases like these, the code for the commit button will more or less look like this
<af:commandButton actionListener="#{bindings.Commit.execute}" text="Ok" action="return" id="commitButton" disabled="false"/>
This approach, presents a very serious hazard, which is a bug in Oracle's JSF implementation. If any exception is thrown after commit, the framework moves to the page designated by the navigation case and the error messages are not being displayed at all.
To make matters worse, you end up with on open transaction and nothing else entered in this manner ever gets stored in your database while you users have no way to realize that something has gone wrong. I had raised an SR for this that ended up in a one off patch (5630740) for JDeveloper 10.1.3.2.
I run into this problem again in am application that I developed recently using JDeveloper 10.1.3.3. And then it hit me. The solution was as simple as the Egg of Columbus. The only thing that needs to be done is to bind the commit button action in a backing bean. JDeveloper will then change the button tag into something like :
<af:commandButton text="Accept" id="commitButton" disabled="false" action="#{backing_Edit.commitButton_action}"/>
... create the following code :
public String commitButton_action() { BindingContainer bindings = getBindings(); OperationBinding operationBinding = bindings.getOperationBinding("Commit"); Object result = operationBinding.execute(); if (!operationBinding.getErrors().isEmpty()) { return null; } return "return"; }
... and that does it. Commit exception messages are displayed correctly and everyone is happy.
In case you have many edit pages with different navigation case labels then you might wish to create a solution that is a little more sophisticated and closer to the OO paradigm. In a case like this I suggest that you create a base class to be the parent of all your page backing beans and add the following method.
public class MyBackingBase { protected String executeCommit( BindingContainer bindings, String successValue) { OperationBinding commitBinding = bindings.getOperationBinding("Commit"); commitBinding.execute(); return commitBinding.getErrors().isEmpty() ? successValue : null; } }
Having done that the actual backing bean code could be something as simple as
public String commitButton_action() { return executeCommit( getBindings(), "return"); }
... and one more thing. The Copy as HTML function is not available again. I guess I 'll have to start looking why .. :-(
2 comments :
hi,
this piece of code and explanation was very informative, i'm a newbie to ADF, JSF etc. i would like to know where you are keeping the details for backing_Edit, i'm finding it difficult to follow and getting compilation error.
First try to create the functionality without the bucking bean.
Then double click on the commit butting and follow the wizard's steps to create a backing bean.
Post a Comment