Handling Rollback Operation for ADF Input Components with Immediate Property. One of my colleagues is implementing advanced dynamic ADF BC/ADF UI functionality. To force validation to be invoked properly, he must use ADF UI input components set with Immediate=true property. This allows to keep validation messages always displayed, even if user navigates to edit another dynamic ADF UI input attribute, until form is submitted or canceled. However, as by JSF design - usage of input components with Immediate=true, blocks execution of command components, if there are validation errors available. This means - user can't use Cancel button to reset the form with validation errors, until he would fix these errors manually. However, there is a potential solution - we could use ADF subform component to isolate input components, with a combination of ADF View reload to refresh rendered UI.
EntityLevelOnly Property To Delay Unique Key Validator. Idea for this post was kindly suggested by real ADF BC guru and evangelist - Steve Muench. You can check famous ADF Not Yet Documented Examples on Steve's blog - Dive into ADF. The main idea is about composite Unique Key, based on multiple EO attributes. Ideally, users should be allowed to change composite Unique Key values, without getting validation errors too early (before trying to save changes). However, this is not the case by default - and I will explain in this post, how to make it work properly with EntityLevelOnly = true property.
Why You Don't Want to Code Validation in Before Commit. You should know by now - there are many things possible in ADF, but it doesn't mean every solution is right, even if it works. One example of such case - coding validation rules in beforeCommit method. This method is invoked after all changes are posted and ADF BC assumes data is valid, if we throw later validation error from beforeCommit - ADF BC state remains unchanged and changed data is not submitted again. There is a workaround to set jbo.txn.handleafterpostexc=true and to force in memory passivation snapshot with subsequent activation on validation error - however, this is a big performance hit. Every time, where there will be validation error - rollback will be executed and entire AM with all VO instances will be re-activated (SQL re-executed and data re-fetched). Today post is about bad practice, to demonstrate why you should not code validation in beforeCommit method.
Workaround for Infamous Bug 13626875. There is such issue logged on Metalink - inputListOfValues Field Not Updated When Selecting A Value Violating A Unique Key. (Doc ID 1402074.1). This is related to LOV functionality and validation. As per Oracle statement - LOV list must include only valid values, list should not return invalid values, this is by LOV design. However, this doesn't sound logical in most of the cases - often LOV may contain complete list of values and for specific attribute we need to enforce validation to accept only a subset of all values available in the list. Despite Oracle answer as such functionality is not possible b design, there is workaround to make it work.
Duplicate Validation Error Message and ADF Bindings. One of the bug requests I was fixing during this week was related to duplicate validation error message display on ADF UI. This was quite annoying to the users - the same validation error message displayed twice.
Coding Validation in ADF BC View Object Before Commit Method. First thing you should do - never implement validation logic in beforeCommit() method, this is especially true for beforeCommit() in VO Implementation class. Why? Because beforeCommit() method will be invoked even if data will not be changed, it is enough just to open VO instance and query data. We can have many VO instances for the same EO and all of them will trigger beforeCommit() methods implemented in VO Implementation. You could open one page, close it without changes and open another page. Once you invoke Commit operation in second page, beforeCommit() method from the VO's involved into first page will be called as well. This means it would trigger validation for the page which is currently closed. On other hand, it is understandable why developers try to code validation logic in beforeCommit(), standard ADF BC validation lifecycle is unpredictable sometimes, it fires validation rules too early. But it still not a good excuse to use beforeCommit() - I will show you why.
Immediately Removing New Row Without Validation in ADF. Once new row is inserted but not yet saved and if validation rules are defined for the attributes - it may cause problems removing this new row (let's say user changes his mind and decides to remove unwanted row). Of course user can invoke Rollback, but this is not what is always desired. User should be able to remove row with one single click - by pressing Delete button. And this is really easy to achieve in ADF, but not always obvious. You need to set Immediate = true as property for Delete button, it will call then Delete operation ignoring any validations for the current row.
Conditional Validation in ADF BC. ADF BC offered out of the box business validation support is quite advanced - allows to control validation execution conditionally. Still some functionality is missing - easy configuration for execution order. Now we have entity and attribute level validations, but really this doesn't give any guarantee that entity level validation will not be invoked when attribute value is changed (especially true for ADF table component). In the future ADF versions I would like to have more control over validation execution order and time. This post is to demonstrate what is available now - conditional validation execution. Validation rule can be executed conditionally in ADF BC, for example depending on user security role (based on use case requirement, we may want to skip certain validation for the super user).
LOV Validation and Programmatic Row Insert Performance. When I work, I think - is not enough just to implement use case, final solution must have good performance and run without side effects. I will give you today one more example and technical hint, to prove such thinking is important. This time I will use example of programmatic insert, when newly inserted row contains attribute with LOV mapping.
Transaction Level ADF BC Entity Validation. Is not so well known, but we can defer validation execution to transaction level for ADF BC entity validators. This can be applied only to Key Exist and Method validators on Entity level and is available in both ADF 11g R1 and ADF 11g R2. It is useful, because it instructs framework to invoke such validation rule only if other validation rules were passed successfully. If validation rule invokes complex code, it may affect performance - each time to invoke it together with other validations. You could defer it for later execution, only if all other validations passed - sounds good.
ADF 11g R2 Model Layer Validation Functionality. There is new functionality available in ADF 11g R2 - ADF Model layer validation. In the most of the cases, we define validation in ADF directly inside ADF BC, on Entity objects. Depending on the use case, not all fields rendered on UI can be based on ADF BC attributes. We can define validations inside Page Definition for any attribute, but specifically it can be useful for transient attributes defined directly in Model layer and displayed on UI. This allows to minimize Java code to control business logic validation for transient fields defined in UI. In this post I will describe how to implement UI fields to capture values for ExecuteWithParams operation and apply Model validation for these fields.
