Help! ADF default behavior rejected by end users...

Question

Hi,
We have built an ADF 11g application during the past months. Last week we had our first user acceptance test with a small group of users. The users were very satisfied about the nice looks of the screens. But they had quite a lot of issues with the default behavior of ADF. I'll provide a list of the most important issues below. I hope more people here at OTN have experienced these issues and perhaps have some workarounds. And perhaps Oracle can use lists like this to improve the next version of ADF...
<ol><li>Multi record edit<br>We have a lot of multi record edit screens. These are all editable tables. Those tables have the following problems:
<ol type="a"><li>Whenever a partial refresh occurs, the whole table gets reloaded. This takes some time, which is uncomfortable. But the main problem here is that the table does not preserve the scroll bar position. The situation can be improved a little bit by setting the <tt>displayRow</tt> attribute to <tt>"selected"</tt> on the table. This will cause the table to show the selected record at the top of the view port after a refresh. But this still confuses the end users. In their experience the records are randomly jumping around.</li>
<li>Records are not always inserted at the bottom. (In fact, they are inserted above the selected record.) End users simply expect records to be inserted at the bottom of the table, no matter what. And I can't disagree with them. Isn't there a setting to achieve this in ADF?</li>
<li>Whenever the user navigates to another record in the editable table, all validation rules on the record he navigates from are fired. That means he cannot leave a required field empty to fill it later. The end users say this is very annoying. We would like to delay all validation until the user presses the Commit button. But as far as I know this is not possible, is it?</li>
<li>The selected record position is not preserved on a full refresh. Our Commit button forces a full refresh of the page. This sounds like a sensible choice to me. However, users tend to click on Commit quite often. But after a full refresh of the page, the currently selected record in a record set is always reset to the first record in the set. In a large data table, this annoys the users very much. Isn't it possible to preserve the selected record over a full refresh?</ol>
<li>Annoying validation errors<br>Many end users are annoyed by the somewhat "persistent" validation error messages. In a larger form or an editable table, users sometimes want to ignore an error and first enter other data, before correcting the error. This is hardly possible, because ADF sets the input focus to fields with errors and keeps popping up windows with a list of fields that have errors. We would like to make the validation less "aggressive". It is okay to give a field a red border if it contains an error. But leave the input focus where it is. And don't show any popup until the user presses the Commit button. And even then show the popup window only once.</li>
<li>ADF BC caching and business rules in the database<br>We have some business rules in our database that automatically fill some fields with default values. We have e.g. a master-details relation, where a value in the master record is calculated based on the values of the detail records. We have set the calculated field in the master record to "refresh after update" and "refresh after insert". Sometimes the value of the field gets refreshed, but sometimes not. Users know that the field should be calculated by "the system", and are asking if they did something wrong if it doesn't. I know we could do the calculation in ADF, but our policy is to have all business rules in the database and to not repeat ourselves (DRY). Is there another way to guarantee that the calculated value in the master record gets updated after an update or insert of one or more detail records?</li>
<li>Partial refresh loses data<br>If a field causes a partial submit to occur, fields in the same record that were not (partial) submitted before lose their data. This forces us to enable partial submit on all fields. But that causes a delay after moving the focus to the next field and validations to be fired too early.</li>
</ol>
I've numbered the items above, please use these number as a reference if you're posting an answer to a specific question.
Please let me know any solution, even if it is only a partial solution. We've a nasty situation now. Our application is (nearly) finished, but it is blocked for production by the users because of the behavior of the ADF framework, on which we have very little influence. We can't blame the users for that, most of their criticism is fully justified. So we have to come up with a good solution for these issues before we can go to production. So any help would be highly appreciated!
Best regards,
Bart Kummel
PS.
We're using JDeveloper/ADF 11.1.1.1.0, we deploy to a WebLogic 10.3.1 server and we have an Oracle 10g database. We're using the full ADF stack: ADF Business Components, ADF Bindings and ADF Faces.

Answer 1

Hi Bart,
I can answer for few of your questions.
Bart Kummel wrote:
Hi,
We have built an ADF 11g application during the past months. Last week we had our first user acceptance test with a small group of users. The users were very satisfied about the nice looks of the screens. But they had quite a lot of issues with the default behavior of ADF. I'll provide a list of the most important issues below. I hope more people here at OTN have experienced these issues and perhaps have some workarounds. And perhaps Oracle can use lists like this to improve the next version of ADF...
<ol><li>Multi record edit<br>We have a lot of multi record edit screens. These are all editable tables. Those tables have the following problems:
<ol type="a"><li>Whenever a partial refresh occurs, the whole table gets reloaded. This takes some time, which is uncomfortable. But the main problem here is that the table does not preserve the scroll bar position. The situation can be improved a little bit by setting the <tt>displayRow</tt> attribute to <tt>"selected"</tt> on the table. This will cause the table to show the selected record at the top of the view port after a refresh. But this still confuses the end users. In their experience the records are randomly jumping around.</li>You can set the fetchSize in the iterator to a minimum value (Say if you are displaying 20 records in the table at a time, you can set the fetchSize to 20, so that, it will fetch only 20 records at a time, and the remaining records on demand basis, i.e they will be fetched when you scroll in the table).
<li>Records are not always inserted at the bottom. (In fact, they are inserted above the selected record.) End users simply expect records to be inserted at the bottom of the table, no matter what. And I can't disagree with them. Isn't there a setting to achieve this in ADF?</li>I suppose you are using the default createInsert operation. You can write your own method instead of the default createInsert, which would have something like
public void customCreateInsert(){
vo.last();
vo.createInsert();
}You can expose this method as method action and use it in place of default CreateInsert.
<li>Whenever the user navigates to another record in the editable table, all validation rules on the record he navigates from are fired. That means he cannot leave a required field empty to fill it later. The end users say this is very annoying. We would like to delay all validation until the user presses the Commit button. But as far as I know this is not possible, is it?</li>You can set the immediate property to true for the column for which you want to skip the validation. However, the validation will fire when you submit / commit the changes (which is expected).
<li>The selected record position is not preserved on a full refresh. Our Commit button forces a full refresh of the page. This sounds like a sensible choice to me. However, users tend to click on Commit quite often. But after a full refresh of the page, the currently selected record in a record set is always reset to the first record in the set. In a large data table, this annoys the users very much. Isn't it possible to preserve the selected record over a full refresh?</ol>Again, you can have a custom method, which would get the current row, commit the transaction and do a setCurrentRowWithKey to point to the last selected record after commit.
<li>Annoying validation errors<br>Many end users are annoyed by the somewhat "persistent" validation error messages. In a larger form or an editable table, users sometimes want to ignore an error and first enter other data, before correcting the error. This is hardly possible, because ADF sets the input focus to fields with errors and keeps popping up windows with a list of fields that have errors. We would like to make the validation less "aggressive". It is okay to give a field a red border if it contains an error. But leave the input focus where it is. And don't show any popup until the user presses the Commit button. And even then show the popup window only once.</li>You can add a af:messages tag in the top and set globalOnly to true. Also, set the immediate property for the items to skip the validation when they tab out.
<li>ADF BC caching and business rules in the database<br>We have some business rules in our database that automatically fill some fields with default values. We have e.g. a master-details relation, where a value in the master record is calculated based on the values of the detail records. We have set the calculated field in the master record to "refresh after update" and "refresh after insert". Sometimes the value of the field gets refreshed, but sometimes not. Users know that the field should be calculated by "the system", and are asking if they did something wrong if it doesn't. I know we could do the calculation in ADF, but our policy is to have all business rules in the database and to not repeat ourselves (DRY). Is there another way to guarantee that the calculated value in the master record gets updated after an update or insert of one or more detail records?</li>We need some more information. Do you see any "pattern" on which this things occur?
-Arun